Approval workflows auditors actually trust

Building a document approval flow in SharePoint and Power Automate takes an afternoon. Building one that an auditor will accept as evidence takes more thought. The difference is rarely in the happy path. It is in what happens when someone edits a file after approval, goes on holiday, or approves their own request.

This article covers the design decisions that make an approval workflow hold up when someone outside the team starts asking questions.

What an auditor wants to see

An auditor does not care how elegant your flow is. They want to answer a few simple questions for any document, months or years later:

Which exact version of the document was approved?
Who approved it, when, and in what role?
Was that person allowed to approve it?
Could anyone have changed the document or the record of approval afterwards?
Is the record still there for as long as the rules require?

Every design choice below serves one of these questions. Anything that weakens the answer to one of them is a problem.

A document's life in an audit-ready workflow.

Tie approvals to a specific version

The most common weakness we find is an approval that points to a document, not to a version of it. The file gets approved on Monday, edited on Tuesday, and the library still shows "Approved".

Start with the library settings:

Turn on major and minor versioning, so drafts are minor versions and approved documents become major versions.
Require check-out for editing in libraries where documents go through formal approval.
Use content approval or a status column that resets automatically when the file changes.

In the flow itself, capture the version label and the file's ETag or hash at the moment the request starts. When the approval completes, compare them again. If the document changed in the meantime, the approval should be rejected or restarted, not quietly applied to the new content.

Lock what has been approved

After approval, move the document to a state where it cannot be edited without starting a new cycle. Options include publishing as a major version with restricted edit permissions, moving it to a read-only library, or applying a retention label that marks it as a record. Pick one approach and apply it consistently.

Build an audit trail that cannot be edited

A comment in a SharePoint list column is not an audit trail. Anyone with edit rights on the list can change it, and version history on list items can be trimmed.

A useful audit trail has these properties:

Append-only. Entries are added, never updated or deleted by the workflow or by ordinary users.
Stored separately from the documents, with permissions that business users do not hold.
Complete. Every request, decision, reassignment, reminder, timeout and cancellation is recorded.

In practice, we write approval events to a dedicated log: a Dataverse table with auditing enabled, a locked-down SharePoint list that only a service account can write to, or an Azure storage table. The Microsoft Purview audit log adds a platform-level record, but its retention depends on your licensing, so check what your tenant actually keeps before relying on it.

What to log for each event

For every step, record at minimum:

document ID, library, and version label
file hash or ETag at the time of the decision
request ID and workflow version
actor's identity (user principal name and object ID, not just display name)
the role in which they acted, such as approver, delegate or administrator
decision and comment
timestamp in UTC
for delegated actions, on whose behalf the action was taken

Log the identity of the person who clicked, not the identity of the flow's connection. Flows often run under a service account, and that account should never appear as the approver.

Enforce separation of duties

The rule is simple: the person who prepares or submits a document should not approve it. In a small organization, that rule gets broken the first time the only other approver is unavailable.

Enforce it in the workflow, not in a policy document:

Before assigning an approval, check that the approver is not the author, the submitter or the last editor of the document.
Resolve approvers from roles or groups maintained outside the flow, so that people cannot add themselves.
If no valid approver exists, stop and escalate. Do not fall back to "anyone in the group".

For higher-risk documents, consider two approval levels where the second approver comes from a different department.

Handle delegation and absence explicitly

People go on holiday, change jobs and leave the company. An approval workflow that ignores this either stalls or invites shortcuts.

Design delegation as a feature with its own rules:

Delegations are recorded in a separate list with a start date, an end date and an approver who confirmed them.
The workflow checks active delegations when it assigns a task and records both the original approver and the delegate.
Delegates cannot approve documents they authored, even when acting for someone else.
Pending tasks escalate after a defined time to a named fallback role, and the escalation is logged.

Avoid relying on out-of-office replies or on people forwarding approval emails. Both break the link between the decision and the person who was authorized to make it.

Plan retention from day one

Approval records must outlive the people who created them, and sometimes the system itself. Retention periods depend on the document type, your industry and local law, so agree on them with whoever owns compliance in your organization before you build.

Then apply them in the platform:

Use Microsoft Purview retention labels on approved documents and on the audit log.
Make sure the flow's run history is not your only record, because it is kept for a limited time.
Document how you would export the full trail for one document, and test that export.

Test the workflow like an auditor would

Most teams test that an approval goes through. Fewer test what happens when things go wrong. Before go-live, run through cases like these:

The author tries to approve their own document.
The document is edited while the approval is pending.
The approver is removed from the group mid-cycle.
A delegation expires during an open task.
Two approvers respond at almost the same moment.
The flow fails halfway and is resubmitted.
An administrator cancels a request.

For each case, check both the outcome and the log. A correct outcome with a missing log entry still fails an audit.

If you cannot reconstruct a decision from the log alone, without asking anyone, the log is not finished.

Common mistakes

Storing the approval status in an editable column with no history.
Approving a document link instead of a specific version.
Running the approval action under a service account and logging that account as the approver.
Allowing approvers to be chosen freely in the request form.
Relying on flow run history as the long-term record.
Changing the workflow in production without versioning it, so old approvals no longer match the current logic.
Treating delegation as an email forward rather than a recorded, time-limited permission.

Where to start

If you already have approval flows in place, pick your most audit-sensitive process and ask the five questions from the beginning of this article. Where the answer is "we would have to check with someone", there is a design gap.

Closing those gaps is usually less work than it sounds. Versioning, a proper log and an enforced separation of duties cover most of what auditors look for.