Home / Features / Access and record integrity
FeatureA record is only worth
what it cannot be changed into
A purchasing file matters because somebody outside your team may eventually rely on it. That only holds if entries were written as work happened, cannot be quietly revised afterwards, and were made by people whose access you can account for.
Three properties, none of them optional
A file can be complete and still be worth very little if any of these are missing, because each one is what stops a reasonable person asking whether it was written after the fact.
Three properties, none of them optional
A file can be complete and still be worth very little if any of these are missing, because each one is what stops a reasonable person asking whether it was written after the fact.
- Entries cannot be revised later
- Approvals attach to a version
- Every action has a name behind it

Entries cannot be revised later
Activity is written as work happens and left alone. A correction is added as a new entry rather than replacing the original, so the history shows what was thought at the time as well as what was concluded.

Approvals attach to a version
A decision is recorded against the exact revision that was read. Uploading a later version does not inherit the earlier approval, which closes the most common gap in document based sign off.

Every action has a name behind it
Uploads, approvals, completions and modifications all carry the person and the moment. Nothing is attributed to a process or a shared account.
Scoped by role rather than granted per person
Permissions granted individually as people ask for them are the reason most organisations cannot say why a particular person can see a particular thing.

Granted per person
Access is given individually as requests come in, and after a few years the permission set is a history of favours rather than a design.

Granted per role
A role carries its scope, so reviewing who can do what means reviewing a handful of roles rather than every individual in turn.

Permissions accumulate
Somebody moves from buying to finance and keeps both sets of access, which is how people end up able to approve their own work.

Access follows the role
Moving role moves the access with it rather than layering the new scope on top of the old one.

A gap appears
Removing somebody sometimes takes their history with them, which leaves a record that cannot explain who did what.

History is preserved
Access is removed while their entries remain attributed to them, because the record describes what happened rather than who currently works here.

Person by person
Auditing permissions means going through every user individually and reconstructing why each grant was made.

Role by role
There are far fewer roles than people, so a permissions review is a short exercise with a clear answer.
Three protections working together
Each of these closes a specific way a purchasing file can be made to say something it did not say at the time.
Entries are written as work happens and cannot be edited or deleted afterwards. Where something was wrong, the correction is added as a further entry, so the sequence shows both the original view and the revision.
- Written at the moment the action occurs
- Not editable or removable afterwards
- Corrections appear as corrections rather than replacements
- Sequence of events provable rather than asserted
A reviewer approves a specific revision. If a later version is uploaded, the earlier approval does not carry across and the phase returns for review, which prevents a reviewed document being quietly replaced.
- Decision recorded against the revision reviewed
- Later uploads do not inherit an earlier approval
- Prior versions retained rather than overwritten
- Closes the most common document sign off gap
Changing a template affects awards created afterwards. Existing awards keep the template they were created under, so a configuration change cannot alter what a past record required.
- Template changes apply to new awards only
- Historic awards keep their original phases and rules
- No retrospective rewriting of what was required
- Old files stay worth producing
Four moments the properties are tested
An approval is challenged
Answered with the approver, the timestamp and the exact version they reviewed.
Learn moreSomebody changes role
Access moves rather than accumulating, so nobody quietly ends up approving their own work.
Learn moreA document is replaced late
The prior approval does not carry, so the phase returns for review instead of appearing signed off.
Learn moreAn external request arrives
The record is producible because it was written as work happened and could not have been revised since.
Learn moreQuestions about access and record integrity
Can activity entries be edited after the fact?
What happens if a document is replaced after approval?
How is access controlled?
What happens to somebody's history when they leave?
Can an administrator change a rule retrospectively?
Can somebody approve their own work?
Who can see which awards?
Other parts of the same workspace

Team and roles
Who can see and do what, and how that changes when somebody moves role.
Learn more
Document approval
Approvals recorded against the version reviewed rather than the file.
Learn moreAsk us the awkward questions
Bring your security and access requirements to the call. Where the answer is that something needs your own review, we will say so rather than talk around it.
Book a demo