Keep an audit trail of every approval

Power Automate does not keep a company-wide approval record you can rely on, and flow run history is kept for only 30 days. Add a step after Start and wait for an approval that writes who, what, when and the decision to a SharePoint list, then turn on version history for that list.

Why an audit trail matters

Sooner or later someone asks, "Who approved that?" It may be a manager, a customer, an auditor or a new teammate. If the answer is "let me search my email," you do not have a record. You have a memory.

An audit trail is simply a record that shows what happened, in order, so you can answer that question in a minute. It does not need to be fancy. It needs to be complete, easy to find and hard to change by accident.

What a record needs

Every approval should leave four facts behind:

Who. The person who asked and the person who decided.
What. The thing that was approved, with enough detail to know it later. A name, a number, an amount or a link to the file.
When. The date and time of the request and of the decision.
Decision. Approved or rejected, plus the comment the approver gave.

Two extras help a lot. A comment from the approver explains the "why". A link back to the original request lets someone open it in one click.

Where Power Automate keeps approval history

When you use the "Start and wait for an approval" action, the request goes to the approvals center. Approvers see pending requests on the Received tab (Action items, then Approvals). The person who sent a request finds it on the Sent tab, and Microsoft says the History tab shows the requests you canceled.

Export approval history

Microsoft's approvals pages describe the Sent and History tabs for viewing requests. They do not describe a built-in export of approval history to a file. Microsoft says approval flows are saved in Dataverse. For a record you can search and report on, write each decision to a SharePoint list as described below.

Approvers can respond from email, the approvals center or the Power Automate app. Microsoft also says that when you assign an approval to people outside your environment, they are given the Approvals User security role, and that they need this role for their responses to be processed and kept in their approvals history.

That history is useful for a person checking their own requests. It is a weak choice for a company record, for three reasons:

It is spread across people. Each person sees their own requests, not the whole picture.
It is hard to search by project, customer or amount.
It is not set up the way you would set up a record. You cannot add your own columns or reports to it.

How long the flow run is kept

The flow that runs the approval has its own history. Microsoft lists a run duration limit of 30 days, and says this includes flows with pending steps like approvals. After 30 days, pending steps time out. Microsoft also lists run retention in storage of 30 days, counted from the start time of the run.

In plain words: the flow's own run history is not a long-term archive. If you need to show a decision a year from now, copy the facts somewhere that you control. A SharePoint list is a good place.

If your approvals may take longer than 30 days, Microsoft says to store them in Microsoft Dataverse and use two flows: one to send the request, and one to act on the response. It names the "Create an approval (v2)" action for this. This is a bigger change, so one way to start is to keep requests short and add reminders so they do not wait that long. See "Remind an approver who has not answered after two days".

Step 1. Create the record list

Make a SharePoint list called "Approval log." Use the Title column for the name of the request.

Add these columns:

Requested by (Person)
Approver (Person)
Requested on (Date and Time)
Decision (Choice): 1 Pending, 2 Approved, 3 Rejected
Decided on (Date and Time)
Approver comment (Multiple lines of text)
Link to request (Hyperlink)

Step 2. Write the request into the list first

Start the flow when a new item is added to the list. This is the same pattern Microsoft uses in its example, where the flow starts when someone adds a request to a SharePoint Online list. The row exists before anyone decides, with Decision set to 1 Pending. That way, a request that gets stuck is still on record.

Step 3. Write the outcome back

After the "Start and wait for an approval" action, add a Condition that checks the approver's response. Microsoft's example uses the Responses Approver response value, "is equal to," and the word Approve. Then, in each branch, add the SharePoint "Update item" action. Microsoft says the Site Address, List Name, Id and Title fields are required for that action.

In the Update item action, fill in:

Decision: 2 Approved in one branch, 3 Rejected in the other.
Approver comment: the comment the approver typed. Microsoft's example offers a "Responses comments" value for this.
Decided on: the time the flow ran. One way to start is to use the flow's current time value.
Approver: the name of the person who responded. Microsoft's example offers a "Responses Approver name" value.

Exact names may differ on your screen.

Step 4. Turn on version history

Version history records every change to a row. Microsoft says that when versioning is enabled, new versions are added to an item's history after changes are saved. To set it up, open the list, select the Settings gear, then List Settings, then Versioning settings. One option there is to create a version each time you edit an item in the list.

To look at the history of a row: next to the item, select the three dots, then Version history. Microsoft says the dialog lets you view, restore or delete an earlier version. If a decision is ever changed, you can see the old value and the new one.

Microsoft's page also lets you limit how many versions are kept. For an audit trail, one way to start is to keep that limit high, or leave it unlimited if your options allow. Ask your admin what fits your storage.

Step 5. Control who can edit the log

A record is only as good as its protection. Think about who can change a row after it is decided.

Give most people read access to the log, or no access at all.
Give the flow's account the right to edit, since the flow writes the decisions.
Keep the list of owners small.

Step 6. Test with a real request

Send one real request through. Check these things:

A row was made with Decision set to 1 Pending.
After you approve, the row says 2 Approved with the date and the comment.
After you reject a second test, the row says 3 Rejected.
Version history shows the row changing from Pending to the final decision.
The Link to request opens the original.

What to avoid

Do not use email as your only record. The reply exists, but nobody can search all of them.
Do not rely on the flow run history. Microsoft lists 30 days for run retention.
Do not let people type the decision themselves if the flow can write it. A typed decision can be wrong or forgotten.
Do not skip the Pending row. Without it you cannot see requests that never got an answer.
Do not delete rows to "clean up." Close them with a status or move them to an archive list instead.
Do not give everyone edit rights to the log.
Do not keep a personal copy in a spreadsheet. It will drift from the real record.

Honest limits

A list records what the flow writes. It does not prove that the right person thought carefully before they clicked. It also cannot catch an approval given outside the flow, such as a hallway yes. If your rules require a legal or regulated record, ask your compliance team what they need before you rely on a list. Licensing for Power Automate and Dataverse differs by plan; check with your admin.

For a record that Microsoft logs for you in Teams, see "Teams approvals vs email approvals". For the problem that starts all of this, see "Approvals lost in email: how to stop chasing sign-offs". For files that need sign-off, see "Document approval in SharePoint: built-in approval or a flow?". For money requests, see "Expense approval with a SharePoint list".

When to get help

You can build all of this yourself in Microsoft 365. If you would rather have it built and tested for your team, I do that. A tracker like this is a fixed price: $5,000 for one, built in 2 weeks. See "What a SharePoint tracker costs to build". Bring one example of the problem to a free call.

Tell me what's still manual

I am Al Davies. I run 250 High Street LLC and build SharePoint trackers and Power Automate flows for operations teams. I work remotely. The first call is free, and I will not try to sell you anything.

See trackers I built: Tools I built

FAQ

What should an approval record include?

Who asked, who decided, what was approved, when each happened, and the decision with the approver's comment. A link back to the request helps too.

Can I just use the Power Automate approvals center as my record?

It shows requests on the Sent tab and canceled ones on the History tab, but it is per person and you cannot add your own columns. It is better as a working view than as a company record. Copy the decision into a list.

How long does Power Automate keep run history?

Microsoft lists run retention in storage as 30 days, counted from the run start. Pending steps such as approvals time out after 30 days. Do not use run history as a long-term archive.

Can I export approval history from Power Automate?

Microsoft's approvals pages describe the Sent and History tabs but no export. Write each decision to a SharePoint list instead.

What values does an approval return?

For the Approve/Reject types, Microsoft's example checks whether Responses Approver response is equal to Approve. With Custom Responses, the values are the options you define.

Where are approvals stored?

Microsoft says approval flows are saved in Dataverse, and people outside your environment get the Approvals User role so their responses are kept in their history. For approvals over 30 days, Microsoft says to use two flows with Create an approval (v2).