TL;DR
- A client's email-based approvals could only recover 40% of their records when audited. A Power Automate flow we'd built produced all 847 approval records in 3 minutes.
- Email is not a record system — it was never designed to be one. Approvals that only exist in inboxes will fail compliance audits.
- Every approval workflow we build writes timestamped, tamper-evident log entries to a dedicated SharePoint list at every step.
- Build the audit log first, then build the approval flow around it. Adding it retroactively costs more and takes longer.
A client called us 8 months after we finished their approval workflow project. They were being audited. The auditors wanted proof of every procurement approval made in the past 12 months: who requested it, who approved it, when, and what the approval decision was.
With their old email-based process, they could find about 40% of it. Some emails had been deleted. Some inboxes had been archived when people left the company. Some approval chains had never made it to a central folder. The auditors were not impressed.
With the Power Automate flow we'd built 8 months earlier, they opened Power BI, filtered by date range, and exported the complete record for all 847 approvals in 3 minutes. Every approval. Every approver. Every timestamp. Every decision. No gaps.
That's the difference between building audit trails as a design principle versus treating them as an afterthought.
What an Audit Trail Actually Is
An audit trail is a timestamped, tamper-evident record of every action taken in a process. For an approval workflow, that means capturing: who submitted the request, what they submitted, at what time, who received it, what decision they made, at what time, any comments or conditions attached to the decision, any escalations that occurred, and the final outcome.
If any of these are missing, your audit trail has gaps. Auditors count gaps. Regulators count gaps. Courts count gaps. "We can provide most of it" is not a satisfactory answer in a compliance context.
In most regulated industries — financial services, healthcare, construction procurement, food manufacturing — the inability to produce a complete approval record is treated the same as not having done the approval at all. "We approved it but can't prove it" is not a defence.
Why Email-Based Approvals Fail Audits
Email is not designed as a record system. That's not a criticism — it was designed for communication, and it's excellent at that. But the properties you need from a record system are not properties email has.
Emails get deleted. Company policy, storage limits, and human tidiness all work against email as a long-term record. The approver's "yes, approved" reply might exist in the sender's Sent folder — if they haven't cleared it. The original request might exist in the recipient's inbox — if they haven't deleted it. The approval might have come verbally in a meeting and been followed up with an email that was filed in a folder nobody else knows about.
When someone leaves the company and their mailbox is archived or deleted, some of those approvals go with them. Email doesn't have tamper evidence — an email can be edited in a client or forwarded with altered content. And there's no central record. The approval for a single procurement request might be scattered across 5 people's inboxes in 5 different folders.
Email approvals are scattered across personal inboxes and subject to deletion. A SharePoint audit log captures every approval decision in one structured, permanent, tamper-evident location.
How We Build the Audit Trail in Power Automate + SharePoint
Every approval workflow we build writes a log entry to a dedicated SharePoint list at each step. Not just at the end — at each step. This matters because partial completions are common: an approver at Stage 1 might approve, but the process fails at Stage 2. The audit trail needs to show the Stage 1 approval even if Stage 2 never happened.
The SharePoint list columns we use for every audit log: RequestID (linked to the main request record), Step (e.g., "Stage 1 — Line Manager"), Actor (the approver's display name), ActorAADObjectID (their Azure Active Directory object ID — permanent even if they change their name or UPN), Timestamp (UTC, not local time), Decision (Approved, Rejected, Escalated, Returned for Information), Comments (any text the approver added), and Metadata (request type, department, value if applicable).
This list has no edit permissions for regular users. Only the Power Automate service account can write to it. This makes the log tamper-evident. A user cannot open SharePoint and delete their approval record. A manager cannot ask IT to remove an inconvenient decision. The only way records are created or modified is through the automated flow.
The audit log SharePoint list captures every step, every actor, every decision, and every timestamp. The list is write-only for the automated flow — users cannot edit or delete entries.
Generating Compliance Reports On Demand
Because the audit data lives in a SharePoint list, Power BI connects to it directly using the SharePoint Online List connector. We build a standard compliance report for every client that includes: all approvals in a specified date range, broken down by approver, by request type, by outcome, and by department.
When an auditor asks — and they will ask — you run the report, filter by the date range they specified, and export to Excel or PDF. The whole operation takes about 3 minutes. Compare that to the alternative: trawling through email archives, asking people to dig through their sent folders, chasing former employees for their archived mailboxes. We've seen that process take 3 weeks. Sometimes longer.
The Power BI report also serves an operational purpose. Approval process owners can see bottlenecks in real time: which approvers have the longest average response times, which request types have the highest rejection rates, whether escalations are happening more frequently than they should. The audit trail is the data source for process improvement, not just compliance defence.
The 4 Properties Every Compliance-Grade Audit Trail Needs
We check every audit trail we build against four properties before calling it done:
Completeness. Every step is recorded, with no gaps. This means writing a log entry not just at the final decision point, but at every stage transition, every escalation trigger, and every reminder sent. If something happened in the process, there should be a record of it.
Immutability. Records can't be edited or deleted by users. This is enforced through SharePoint permissions: the audit log list has view-only access for all users and list owners. Only the Power Automate service account can write to it. Immutability is what distinguishes an audit trail from a spreadsheet someone maintains.
Timestamp precision. UTC timestamps, not local time or "approximate date." Local time changes with daylight saving. Approximate dates don't hold up under scrutiny. Power Automate's utcNow() function captures the exact moment of each action in UTC, down to the second.
Identity certainty. We store Azure AD object IDs alongside display names. Display names change — people get married, change names, update their profiles. UPNs (user principal names) change when someone moves departments. Azure AD object IDs never change for the lifetime of the account. If an auditor needs to verify who approved something 5 years ago, the object ID is the only identifier that will still resolve correctly.
Don't Build This as an Afterthought
Every time we've been brought in to add an audit trail to an existing Power Automate workflow, it takes longer and costs more than it would have to build it in from the start. The SharePoint list structure needs retrofitting. The Power Automate steps need new actions inserted at each stage. The permission configuration needs rethinking. Existing data has to be migrated if there's any historical record to preserve.
If you're about to build an approval workflow: design the audit log first. Sketch the SharePoint list columns before you touch Power Automate. Then build the flow with audit logging steps included at every stage transition. The logging adds maybe 20% to the build time. Retrofitting it later adds 60% or more, and still leaves a gap in your historical records for the period before the retrofit.
We treat the audit log SharePoint list as the first deliverable on every approval workflow project — before any flow is built, before any form is designed. If the audit trail isn't designed correctly, nothing else about the workflow matters when the auditors come calling.
Key Takeaways
Email is not a record system. Approvals that only exist in personal inboxes will fail compliance audits — not because the approvals didn't happen, but because you can't prove they did.
Use Azure AD object IDs for approver identity in your audit log, not display names or email addresses. Object IDs are the only identifier that remains stable across the full lifetime of an account.
Build the audit log first — design the SharePoint list columns before touching Power Automate. Adding it retroactively costs more and leaves historical gaps you can never fill.