Segregation of Duties and Human Override in Automated Approval Workflows: A Control Framework

By Michael Branson

Quick answer. As of September 2026, under NIST SP 800-53 control AC-5, classify each automated approval by the action it can complete, not by the department that owns it. Where a single identity can both initiate and complete that action, the approval is a control and needs a second named human who is not the requester, not the flow owner, and not the owner of the connection the flow runs on; where no single identity can complete it alone, the approval is a notification and should be treated as one. Every approval that is a control records which human decided, when, on what evidence, and whether an override was used and by whom, and the override is designed before the happy path, because an override with no second name and no record is the finding an auditor writes up, not the control that was supposed to prevent one.

When your internal audit function asks, in writing, how you know that the person who raised a purchase requisition, a vendor bank-detail change, a journal entry or a privileged access request was not also the person who approved it, the honest answer at most Microsoft-stack shops is that nobody has checked. The pattern behind that answer is a familiar one: a flow that runs on whichever employee’s credentials happened to own the connection when it was built, an approver group assembled in a hurry years ago and never re-derived since, and a manual override the business insisted on at go-live that carries no second name and no written record of who used it or why. None of that shows up until an examiner or an auditor asks for it by name, and this page is written for the point before that conversation, not after it.

Which of your approvals are actually controls

NIST SP 800-53 control AC-5, Separation of Duties, does not hand you a list of approvals to split. Its first clause is an instruction to make one: “Identify and document [Assignment: organization-defined duties of individuals requiring separation].” That is the right starting question for a Microsoft 365 or Power Platform estate, because most tenants never wrote that list down before they started automating approvals, and a flow built to speed up a process is not the same thing as a flow built to control one.

Run every approval in your estate through one test: can a single identity, acting alone, both start this action and finish it? A travel-request approval that only notifies a manager after the fact is not a control; nothing is being separated, and adding a second approver there produces exactly the shadow process automation was supposed to end. A payment-initiation flow where the requester’s own Power Automate connection can also complete the payment step is a control, whether or not anyone designed it as one, because AC-5’s discussion names precisely this risk: “Separation of duties addresses the potential for abuse of authorized privileges and helps to reduce the risk of malevolent activity without collusion.” The classification is mechanical once you ask it this way: notification approvals stay simple, control approvals get the rule below. A gap found this way is a design finding about the approval itself, a different finding from a SOX access-control finding; Your Auditor Flagged Access Controls. Here Is the SOX Remediation Plan. is where an access-review finding gets remediated, and this page does not restate that work.

This is a different question from whether the same access is separated at the identity layer; that boundary is addressed in the counter-case below. This control is one piece of your organization’s broader Workflow Automation Services Built for Enterprise IT Environments program, and a tenant-wide Power Platform governance program is the wider container it sits inside; if you have not yet designed that container, the work here still stands on its own, and Designing a Power Platform Governance Framework That Holds Up in a Regulated Enterprise is where the container itself gets built.

The rule, and the three people your second approver cannot be

Once an approval is classified as a control, the rule is short: it needs a second named human who is neither the requester, nor the flow’s owner, nor the owner of the connection the flow executes under. The third of those three is the one most Power Automate estates get wrong without noticing, and it is a documented mechanic, not a guess. Microsoft’s guidance on connection references states it plainly: “When a flow is turned on (enabled), the user turning on the flow needs to own or have permission to use all the connections in the flow.” A flow does not act as an abstraction; it acts as somebody, and if that somebody is also the approver, your control is a single identity wearing two hats regardless of how the approval step is drawn on a diagram.

This is the mechanism behind a defect that never shows up in a flow diagram: the approver field can read correctly and the control can still be void, because the identity actually executing the approval action is the connection owner, not the named approver. Who owns a flow’s connections, and what breaks when that owner changes roles or leaves, is a design question with its own answer; Power Automate Connection References and Flow Ownership is where that gets designed, and this page assumes that design exists rather than re-deriving it. A fourth person sometimes belongs on the exclusion list too: where the approval also benefits the approver directly, the beneficiary is excluded on the same logic as the requester, even when the two are formally different fields in the flow.

What Power Automate and Microsoft Entra already enforce, and what they do not

Some of this rule is a platform behavior you can point to; the rest is a design decision your organization has to make and document, because Microsoft Learn is silent on it. Keeping the two apart matters, because writing a design decision as though it were a guaranteed capability is a common way this control fails once someone actually tests it.

The strongest documented example sits in Microsoft Entra Privileged Identity Management. Microsoft’s own page on approving or denying PIM requests, read live at Microsoft Learn this month, states: “Approvers aren’t able to approve their own role activation requests. Additionally, service principals aren’t allowed to approve requests.” That is a real, product-enforced self-approval bar, and it applies to Entra role activation, not to a Power Automate approval step.

Power Automate does not document the same bar for its own approvals. Microsoft’s top-scenarios guidance for approval flows documents something narrower instead: “if you are the requester, you cannot reassign the approval request.” Reassignment and self-approval are different mechanics, so a Power Automate approval that must never be completed by its own requester is a design your organization builds into the flow and the approver group, not a behavior the platform guarantees on its own. Two more places Microsoft Learn stays quiet are worth naming before someone assumes otherwise: Learn documents the reassignment action in the approvals UI but does not document what record that action leaves behind, so the evidence of a reassignment has to be confirmed against your own tenant’s run history rather than assumed to exist; and Microsoft’s access reviews overview lists Self-review as a supported reviewer option, with no caution attached to it, so a self-reviewed access review is a configuration choice your organization makes and owns, not something Microsoft warns you away from.

None of this holds if the platform underneath the approval is not secured; a Power Automate approval step is only as trustworthy as the connectors, data-loss-prevention policies and service accounts it runs on, and Securing Power Automate in Regulated Enterprises is where that architecture gets designed. Whether a given approver needs a premium Power Automate license is a separate, purely licensing question this page does not answer; Do Power Automate Approvers Need a Premium License? The Licensing Rule, Explained is where that gets resolved.

The override, designed before the happy path

Every approval you classify as a control eventually needs an exception path, and the override is the part of the design nobody writes down, which is why it is the part an auditor asks about first. The right posture toward an override is not to eliminate it; auditing standards already contemplate that some organizations cannot fully separate duties. PCAOB AS 2201 states it directly: “a smaller, less complex company might have fewer employees in the accounting function, limiting opportunities to segregate duties and leading the company to implement alternative controls to achieve its control objectives.” An override, designed correctly, is that alternative control. An override with no second name and no record attached to it is not; it is the gap the standard is describing, left unaddressed.

PCAOB AS 2201 also names automation itself as a risk factor worth weighing, not a free pass: “Whether the control relies on performance by an individual or is automated (i.e., an automated control would generally be expected to be lower risk if relevant information technology general controls are effective).” That “if” is doing real work. An automated approval is only lower-risk than a manual one when the general controls underneath it, including the override path, actually hold.

Design the override with the same rule as the primary approval: name who may invoke it, in writing, before the first exception happens; require that the person invoking it is not the requester, the flow owner or the connection owner, exactly as the primary rule requires; and require a written reason captured at the moment the override is used, not reconstructed afterward from memory. An override designed after the fact, in response to a specific stuck request, is usually built to solve that one incident and ends up silent on every requirement above.

What every control approval has to record

A control approval that produces no record is indistinguishable, after the fact, from one that never ran. The evidence set below applies to every approval you classified as a control above, and it holds regardless of whether the approval ever hit its override path.

Run retention has a real limit worth planning around, not assuming away: Microsoft’s flow limits and configuration documentation states that “run retention in storage” for Power Automate flows defaults to 30 days, “calculated using a run’s start time,” so a record your auditor wants to see six months from now has to be exported or archived before that window closes, not retrieved from the flow’s own run history after it does. Who builds the flows and the evidence capture this table assumes, at the routing and audit-trail level, is its own body of work; Approval Workflow Automation Services for Enterprise Teams is where that gets built.

When this is the wrong shape

An approval that moves nothing does not need a second approver, and adding one anyway is how a control program manufactures the shadow process it was meant to prevent; a notification dressed up as a control wastes an approver’s time on every single request and teaches the business to route around the system the first time it slows down a real deadline.

An organization too small to split a given duty across two people is not a defect this page can design around, and it is the case PCAOB’s own standard already contemplates: the answer there is a documented compensating control, evidenced the same way the primary rule requires, never a second name added to the approval only to satisfy the appearance of a split.

Where the risk is privileged access rather than a business transaction, the identity a person holds, not the approval a flow routes, is what needs the second reviewer; that is an identity control, and it belongs on the Microsoft Entra ID Governance for Regulated Enterprises: Product Scope, Licensing, and Audit-Defensible Implementation page, not inside a Power Automate flow. And none of the four frameworks behind this page orders any of it in these words: NIST SP 800-53 AC-5 is the one that states separation of duties as a control; Sarbanes-Oxley Section 404 does not use the words at all; the one COSO document this page could read in full, Leveraging COSO Across the Three Lines of Defense, does not use them either, though COSO’s own 2013 Framework text is sold rather than published and this page could not check it directly; PCAOB AS 2201 contemplates duties that cannot be segregated and asks what compensates. Treat every sentence above as a description of what these controls constrain and what Microsoft’s platform documents, never as a claim that any configuration, or any framework, has been satisfied. That determination belongs to your own internal audit function and your external auditor, working from your own control narrative.

These controls are rarely designed all at once against a live estate; most organizations introduce them in a sequence, alongside a broader Power Automate rollout, rather than retrofitting every approval on day one. The phased Power Automate rollout guide covers that sequencing question for a mid-sized finance organization; its own SOX section declines to make a SOX-specific claim, in its own words, and leaves the control-design question open for the page a reader lands on next.

How i3solutions approaches it

This page sets out a framework for making this decision; it does not describe work i3solutions has delivered on this specific question. i3solutions workflow automation builds use standard and premium Power Platform connectors, custom API connectors published through Azure API Management, and hub-and-spoke approval patterns built on Dataverse tables or SharePoint lists. Separately, i3solutions runs comparative platform-selection evaluations for clients, recommending among IAM platforms for hybrid estates and among workflow automation platforms against SOC 2 and HIPAA, rather than only implementing the Microsoft option. Applied to this question, that means starting from the approvals your organization already runs, classifying which are controls, naming the second approver and the override owner in writing, and building the evidence trail into the flow itself rather than assembling it after the fact from scattered exports. This page makes no claim that a resulting design closes an audit finding or discharges any framework’s requirement; that determination stays with your audit function, on your own control narrative.

If you want the approvals in your own estate classified against this rule before your next audit cycle, the conversation starts here.

Contact a senior architect

Key Takeaways

• Classify by the action an approval can complete, not by its department: a single identity able to both initiate and complete an action makes that approval a control; one that cannot makes it a notification.
• A control approval needs a second named human who is not the requester, not the flow owner, and not the connection owner the flow executes under, because Microsoft documents that the connection owner is the identity the flow actually acts as.
• Microsoft Entra PIM documents a real self-approval bar for role activation; Power Automate documents only that a requester cannot reassign their own request, which is a different guarantee, so a self-approval bar on a Power Automate approval is a design your organization builds, not a capability the product provides.
• Of the four control frameworks behind this page, only NIST’s separation-of-duties control states the rule directly; Sarbanes-Oxley’s own text does not use the words, neither does the one COSO document this page could read in full (COSO’s Framework text itself is sold, not published, and was not checked directly), and PCAOB’s auditing standard treats an undocumented, unnamed override as the finding, not a documented compensating control as one.
• Power Automate’s run retention in storage defaults to 30 days, “calculated using a run’s start time” (Microsoft Learn, flow limits and configuration, ms.date 2026-07-17, read September 21, 2026), so evidence an auditor will ask for later has to be exported before that window closes.