Procurement Approvals: Event-Driven Flow, Delegation, and Audit

Use an automated cloud flow triggered when a SharePoint item is created, with a trigger condition that the request is submitted, plus Start and wait for an approval for each tier. Do not use a 15-minute recurrence to poll Pending.

The scheduled flow causes duplicates because it evaluates the same item on every run while the first approval is still waiting. A second run sees Pending, starts another approval, and the approver receives two requests. Adding a status check helps, but a poll plus a long-running approval is still a race.

Prevention pattern:

1. Trigger on item creation or on a controlled Submitted action.
2. Immediately set ApprovalStatus to In progress and store the flow run ID.
3. At the top of the flow, terminate if the status is not Submitted.
4. Use sequential approval actions: manager, then finance if amount is at least $5,000, then CFO if amount is above $25,000. Put each tier in a child flow to keep the main flow readable.
5. On completion, write the outcome and set the status to Approved or Rejected.

For delegation, use the Approvals app’s delegation feature so an approver can nominate a backup for a date range. Also maintain an Approvers SharePoint list with a primary and backup, and route to the backup when the primary’s out-of-office dates cover today. Add a timeout on each approval and escalate to the backup rather than letting the request wait indefinitely.

Separate the approval decision record from the request document.

• Decision record: when an approval completes, write approver email, decision, response date, comments, tier, and request ID to an append-only ApprovalHistory list or Dataverse table. Enable versioning and restrict edit/delete permissions. Auditors should read this history, not the current status column alone.
• Attachments: keep the 4 MB files and multi-file requests in a SharePoint document library, with a folder or metadata column for the request ID. Do not attach files to approval emails; email attachments create uncontrolled copies. Link to the document library from the approval and record the file names and versions reviewed in the history row.
• Evidence: capture the approval response comments and the exact attachment version. SharePoint version history plus the history row gives the auditor who, when, and what.

Judgment call: if auditors require immutable records, use Dataverse with auditing enabled for the approval history and store documents in SharePoint with retention labels. A SharePoint list alone can be edited by site owners, so restrict permissions and enable versioning. Do not let the flow overwrite the previous history row; always create a new row per tier.

Failure handling: wrap each tier in a Scope with run-after settings. If the approval action fails or times out, notify the request owner and the backup approver, write a Failed or Escalated status, and avoid automatically retrying the same approval indefinitely. Use retry policy on SharePoint and approval actions, but make the flow idempotent: check for an existing open approval before creating another. At the end, terminate with a clear error if no decision is recorded.

Licensing: SharePoint and the Approvals connector are available with standard Office/Power Automate licensing, and approvers can respond from Outlook or Teams without building flows. If the design stores approval history in Dataverse, the flow owner and anyone using a Power App over that data need premium licensing. If the team stays with SharePoint lists and document libraries, standard licensing may be enough, but the audit and permission model is weaker. Budget premium for the flow owners and the procurement staff who administer the solution, not necessarily for every approver. Confirm whether the CFO’s assistant needs a license to respond on behalf of the CFO; delegation in Approvals is the safer route than shared credentials.