Home / Features / Access and record integrity

Feature

A 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.

Activity entries are append onlyAccess follows the role
What makes a record hold up

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.

Security • Walkthrough

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
ProcureAudit Entries cannot be revised later
Property 01

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.

What that meansA record that carries weight precisely because it could not have been tidied up.
ProcureAudit Approvals attach to a version
Property 02

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.

What that meansNo approval that appears to cover a document nobody actually reviewed.
ProcureAudit Every action has a name behind it
Property 03

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.

What that meansQuestions about who did something have answers rather than inferences.
Access

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.

Book a demo
ProcureAudit Granted per person
The challenge

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.

GrantedPer person
ReviewableBarely
Over timeDrifts
ProcureAudit Granted per role
With ProcureAudit

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.

GrantedPer role
ReviewableEasily
Over timeStable
ProcureAudit Permissions accumulate
The challenge

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.

Old accessRetained
New accessAdded
ResultAccumulation
ProcureAudit Access follows the role
With ProcureAudit

Access follows the role

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

Old accessRemoved
New accessApplied
ResultCorrect scope
ProcureAudit A gap appears
The challenge

A gap appears

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

AccessRemoved
Their entriesAt risk
HistoryDamaged
ProcureAudit History is preserved
With ProcureAudit

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.

AccessRemoved
Their entriesRemain
HistoryIntact
ProcureAudit Person by person
The challenge

Person by person

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

UnitA person
EffortHigh
ConfidenceLow
ProcureAudit Role by role
With ProcureAudit

Role by role

There are far fewer roles than people, so a permissions review is a short exercise with a clear answer.

UnitA role
EffortLow
ConfidenceHigh
How a record resists being rewritten

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
FAQ

Questions about access and record integrity

Can activity entries be edited after the fact?
No. Entries are written as work happens and cannot be edited or deleted. A correction is added as a new entry, so the record shows both the original and the revision rather than only the tidied result.
What happens if a document is replaced after approval?
The earlier approval does not carry to the new version. The phase returns for review, which prevents a reviewed document being quietly swapped for a different one.
How is access controlled?
By role rather than per person. Ten or more role types are available, each carrying its own scope, so permissions can be reviewed as a handful of roles instead of user by user.
What happens to somebody's history when they leave?
Their access is removed and their entries remain attributed to them. The record describes what happened rather than who currently works at the company, so removing a person does not create a gap.
Can an administrator change a rule retrospectively?
No. Template changes apply to awards created afterwards, and existing awards keep the template they were created under. That is deliberate, because retrospective changes would make historic records much less useful.
Can somebody approve their own work?
Reviewers are named per phase in the template, so the reviewer is set before the work is submitted rather than chosen at submission. Where a role change would create that overlap, access follows the new role rather than accumulating.
Who can see which awards?
Scope follows the role. A procurement officer works with their own records, finance reviews the phases where value is the question, and administrators configure the workspace. You decide which roles exist and what each one covers.
Related

Other parts of the same workspace

ProcureAudit Team and roles
FEATURE

Team and roles

Who can see and do what, and how that changes when somebody moves role.

Learn more
ProcureAudit Document approval
FEATURE

Document approval

Approvals recorded against the version reviewed rather than the file.

Learn more
ProcureAudit Tasks and activity
FEATURE

Tasks and activity

The running record of who did what and when across an award.

Learn more

Ask 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