The Power Automate owner left on Friday

The situation: the flow is alive but its authority is gone

Consider a composite but common case. A Perth wholesaler has one production flow that watches a shared mailbox, extracts a purchase request, asks two managers for approval and writes the result into a SharePoint list. The maker built it in the default environment under a personal account. Their employment ended on Friday; the account was blocked and its licences removed.

On Monday the trigger appears intermittent. Existing approval cards remain in Teams, but responses do not advance. Some runs fail at Outlook, others at SharePoint, and a few succeed because cached connections have not yet expired. Managers resend requests, creating duplicates. Finance cannot tell which purchase is authoritative.

The niche danger is the half-working state. A completely dead flow is obvious. A flow using a mixture of personal and shared connections may continue just long enough to create contradictory records.

Containment before repair

First stop the business process from branching. Nominate one temporary intake channel and tell requesters not to resubmit old items. Export the run history and identify the last known-good transaction. Capture the flow definition, solution status, owner list, trigger configuration, connection references, environment, child flows and every destination it can change.

Do not immediately turn the flow off if it is the only record of incoming requests. Instead, decide whether the safer containment state is disabled, trigger-suspended, or monitored read-only. If it sends money, grants access, changes customer records or triggers external work, suspension normally wins.

The recovery lead should record the business owner separately from the technical operator. IT can restore execution, but only finance or procurement can decide which duplicate request represents the valid business instruction.

Read the failure as an identity map

For each failing action, record the connector, connection owner, authentication type and target permission. A single flow may use the former employee for Outlook, a generic account for SharePoint and the respondent’s identity for Approvals. “The flow owner” is therefore not one fact.

Inspect run inputs and outputs without copying sensitive payloads into an uncontrolled incident document. Look for 401/403 responses, missing connection references, invalid consent, mailbox-not-found errors and calls that succeeded but returned an empty result. Check whether the flow is inside a solution, whether connection references exist, and whether any child flow requires the parent owner to have explicit run-only rights.

Then map non-connector dependencies: SharePoint list permissions, mailbox delegation, environment security roles, DLP policy, custom connectors, gateways, secrets and premium licensing. The symptom may begin with account disablement but expose several undocumented assumptions.

Restore service without recreating the same trap

Create or select a governed workload identity appropriate to the connectors. Power Automate cloud flows often still require a licensed service account for user-delegated connectors; application identities are preferable where a supported API and permission model allow them. Do not grant a broad administrator role merely to make the designer show green ticks.

Move the flow into a managed solution if it is not already there. Replace direct connections with connection references, replace hard-coded site and mailbox identifiers with environment variables, and add at least two accountable co-owners. Rebind one connector at a time and run a controlled test after each change. This makes the causal repair visible and preserves a rollback point.

Where an action cannot be transferred safely, rebuild that action in a copy, compare the exported definitions and promote through a controlled release. Editing the only production copy during an incident makes evidence and rollback unnecessarily fragile.

Reconcile the requests created during the grey period

Service restoration is only half the job. Build a reconciliation table from the trigger source, flow run identifier, business request identifier, approval result and target-system record. A business owner must decide the authoritative state for duplicates, missing approvals and transactions that executed externally but failed before the final status update.

Add an idempotency key before replaying anything. In this scenario the purchase-request number plus a stable source-message identifier can prevent a second target record. For flows without a natural key, create one at intake and persist it before side effects begin.

Replay from the reviewed queue using the original correlation key. Forwarding the message creates another trigger event. A replay mechanism should state which steps already happened and which will be repeated. Otherwise recovery can pay an invoice twice while producing a technically successful run.

Verification that proves continuity

Run three tests: a normal request, a rejected request and a request that deliberately fails after the first write. Confirm that the correct identities appear in connector audit logs, approval responses advance once, duplicate protection holds and the target record matches the source. Disable one co-owner in a non-production test and confirm that the backup operator can locate, run and restore the workload from the runbook.

Monitor the next business cycle for queue age, failure count, duplicate detections and manual interventions. The acceptance record should include screenshots or exported logs, but it should not expose the business payload more widely than the production system.

Finally, ask a second operator to locate the flow, explain its dependencies and perform a safe test using only the runbook. If that cannot be done, the system still depends on personal memory.

The durable control set

• Named business owner, technical owner and backup operator.
• Production flows held in solutions with connection references and environment variables.
• Purpose-built identities with the minimum licences and permissions the connector actually requires.
• Source-controlled exports, release notes and a tested rollback path.
• Idempotency and reconciliation for any step with financial, customer or access consequences.
• Quarterly owner/connection review and an offboarding query for flows linked to departing accounts.

A flow survives its maker when identity, ownership, deployment and business reconciliation each have a named control and a tested backup operator.

Repairs that look fast but deepen the incident

Do not unblock the former employee indefinitely, share their password, or assign a global administrator merely to restore a connector. Those actions replace an availability incident with an identity and audit incident. Do not export sensitive flow payloads into email or a general Teams chat for diagnosis.

Avoid rebuilding from memory while the original definition still contains evidence. Avoid replaying from the original trigger without a reconciliation set. Do not treat a successful manual run as proof that schedules, approvals, retries and downstream side effects are safe.

The fastest defensible repair is the one that preserves the current state, narrows authority, and leaves a second operator able to reproduce the verification.