Power Automate and OAuth app sprawl

Power Automate can turn a repetitive task into a reliable process before lunch. Six months later, that same flow may be business-critical, owned by someone who left, and authenticated through connections nobody remembers approving.

The problem is not “citizen development.” It is treating an automation like a personal spreadsheet when it has quietly become production infrastructure.

You can fix that without banning useful automation. Start by separating the identities involved, then give important flows an owner, a support path, and credentials that match their risk.

A flow is not one identity

When reviewing a cloud flow, distinguish four things:

• The flow contains the trigger, actions, conditions, and business logic.
• The owner or co-owners can edit and administer it. A co-owner is not automatically the identity used by every action.
• Connections hold the credentials a connector uses for services such as Outlook, SharePoint, SQL, or a third-party platform.
• The enterprise application or service principal represents an application in Microsoft Entra ID. Its granted permissions may be delegated or application permissions.

That separation matters. Adding a manager as co-owner does not repair an Outlook connection authenticated as a departed employee. Removing an enterprise app because its name looks unfamiliar can break several flows at once. A useful review maps the dependency before changing it.

Microsoft’s permissions and consent overview explains the Entra side. Delegated permissions let an app act on behalf of a signed-in user, within what that user can access. Application permissions let an app act as itself without a signed-in user and require administrator consent. Neither label tells you whether the access is appropriate; you still need to compare the permission with the automation’s job.

Build an inventory that answers operational questions

For each production-relevant flow, record:

• Environment, flow name, URL, and plain-language purpose
• Business owner and technical owner or co-owner
• Trigger type and expected schedule or event
• Every connector, connection owner, and target system
• Data read, changed, sent, or deleted
• Entra application permissions or delegated grants involved
• Last successful run, failure alert destination, and recovery steps
• Business impact if it stops or runs incorrectly
• Whether it is solution-aware and uses connection references

Power Platform administrators can inspect flows, connections, and owners from the Power Platform admin center. Inventory is not a one-time export. New flows appear, connections are reauthenticated, and an innocent edit can change the dependency map. Review critical flows quarterly and before an employee leaves.

Do not trust the title. “Copy new lead” might only create a row, or it might forward customer details to an external service and notify a personal mailbox. Open the actions and inspect the actual connections.

Put a gate around OAuth consent

OAuth consent is an authorization decision, not a login convenience. A polished consent screen and a verified publisher do not prove that an application needs every requested permission.

Set the tenant’s user-consent policy deliberately. Microsoft documents options ranging from disabling user consent to allowing consent only for selected low-impact permissions from verified publishers in its user and admin consent overview. If users cannot self-consent, the admin consent workflow provides a review path instead of forcing requests through side channels.

Before approving an application, answer:

1. Which flow and business process need it?
2. Are the permissions delegated or application permissions?
3. Can the job work with a narrower scope?
4. Which data and users are reachable?
5. Who owns the vendor relationship and removal decision?
6. How will we notice misuse or an unexpected change?

Tenant-wide administrator consent deserves extra care. Microsoft warns in its tenant-wide admin consent guidance that some permissions can provide broad access across mailboxes, sites, or users. Record the justification and review date with the grant. Our weekly Entra checks include new application consent, but a weekly glance does not replace an approval record.

Give important flows durable ownership

Every business flow should have one accountable business owner and at least one technical owner who understands how to support it. Microsoft notes in its cloud-flow sharing guidance that co-owners can edit the flow, view run history, manage owners, and delete it. That is powerful access, so use a small maintained group rather than adding everybody “just in case.”

For production flows, prefer a solution with connection references. A connection reference is a solution component that points to a connection. It makes the dependency visible and makes moving the automation between environments less fragile.

For a mission-critical departmental process, a service principal can remove one employee’s password and employment lifecycle from the run identity. Microsoft specifically supports service-principal-owned flows. This is not a reason to convert every personal productivity flow. It adds application registration, Power Platform application-user, connection, permission, licensing, and secret or certificate lifecycle work. Verify current licensing and connector support, grant only what the flow needs, and assign a human team to own the non-human identity.

A shared administrator account is not a substitute. It hides accountability and creates another privileged password to protect.

Offboard the automation, not only the person

Add this sequence to the normal same-day offboarding checklist:

1. Search every Power Platform environment for flows created, owned, or connected by the departing user. Include the default environment.
2. Classify each flow: retire, transfer, or investigate. Do not delete an unknown flow on sight.
3. Add the approved owner or co-owner. For a non-solution flow, ownership may require copying or export/import rather than a simple owner change; follow Microsoft’s change-flow-owner guidance.
4. Replace user-bound connections with an approved owner or service identity. Rebind connection references where applicable.
5. Run a controlled test that exercises the real trigger and destination. A flow being switched on does not prove its connections work.
6. Configure failure notifications to a monitored team destination, then watch the next scheduled or live run.
7. Only after dependencies are mapped, remove obsolete connections and app grants.

If the account is already gone, a Power Platform admin can assign a new co-owner through the admin center. Microsoft also documents an administrative process for managing orphaned flows. Preserve the flow first, then repair and test its identity chain.

The bottom line

Power Automate sprawl becomes risky when nobody can answer who owns a flow, whose credentials it uses, and what access its applications hold. Inventory those three relationships, govern consent, move durable processes into managed solutions, and test them during offboarding. The goal is not fewer automations. It is fewer business processes balanced on an employee account nobody knew was structural.