Smart Statistics · Automation strategy
Who Keeps the Flow Running? A Power Automate Handover Plan
Your colleague can leave the business. Their knowledge, credentials and unfinished work should not leave your essential workflows without support.
Could another person take over today?
Illustrative example · fictional operations teamEvidence of continuity
Illustrative example · all chart figuresOne flow’s handover trail
SharePoint queue: team access confirmed
Outlook connection: replacement required
Business owner: operations manager
Release decision: awaiting successor test
Illustrative example · statuses are fictional.
The risk appears after the farewell email
Consider a fictional UK facilities business. A coordinator built a Power Automate flow that turns service requests in a SharePoint list into work orders and sends confirmation emails. The process became routine, so colleagues stopped thinking about the automation behind it.
During the coordinator’s notice period, the team adds a colleague as co-owner. Later, the original account is disabled. Some actions lose access, customers do not receive confirmations and the replacement owner is unsure which requests need attention.
Microsoft warns that connections associated with a departing user can cause actions to fail even when a shared flow has another active owner. Co-ownership is useful, but it does not prove that the complete service can survive a departure. [1]
The business consequence is a queue of uncertain work: requests that may be untouched, partly processed or already completed. A good handover must preserve both the ability to operate the flow and the ability to establish what happened.
Trace the dependency behind each action
Start with a single important workflow. Record its environment and flow identifier, business purpose, trigger, destinations and support contact. Then separate the responsibilities below. One person may hold several roles, but the record should show which role they are performing.
| Dependency | Question to answer | Evidence to retain |
|---|---|---|
| Business accountability | Who decides priorities and accepts disruption? | Named process owner, deputy and service deadline. |
| Flow management | Who can inspect, edit and stop the flow? | Verified owner access and an authorised support contact. |
| Connection identity | Which identity authenticates every trigger and action? | Connection or connection-reference mapping, authentication method and renewal responsibility. |
| Resource access | Can that identity access the required list, mailbox, file or system? | Tested permissions, destination locations and gateway dependency where relevant. |
| Entitlement | What licence or capacity supports this flow? | Confirmed licensing route, accountable administrator and review date. |
| Operational knowledge | How do we identify and recover unfinished work? | Runbook, business record identifiers, exception queue and recovery test. |
Choose the ownership route before the leaving date
Retain a supported team flow
For a modest departmental process, trained human owners may be proportionate. Give edit access only to people who support it; document a deputy and replace departing-user dependencies. More owners are not a substitute for clear accountability.
Transfer within a solution
For a solution-aware cloud flow, Microsoft supports an ownership change by a suitably privileged owner or co-owner. For non-solution flows, assess adding the flow to a solution where Dataverse is available, or creating a replacement. [2]
Evaluate an application identity
For an important organisational service, consider a service principal application user as owner. This separates ownership from one employee’s account lifecycle. Check connector authentication and permissions separately: flow ownership does not automatically change connection identities. [3]
Make the decision against the cost of interruption, frequency of staff changes, available administration skills and support effort. A small non-critical notification and a customer work-order process need different levels of assurance.
Confirm the current licensing arrangement with your administrator before changing ownership. Premium service-principal-owned flows have specific licensing options; Microsoft now documents a designated licensed user route as well as capacity options. That route still requires tracking the designated user’s entitlement. [4]
If you create a replacement flow, plan the cutover explicitly. Record the last business item processed by the old flow, prevent both flows processing the same new work, and reconcile the first batch after switching. Decide how existing in-flight runs will finish or be handled before disabling the old route.
Make the handover a rehearsal
Before the change: let the successor lead
Ask the successor to find the flow from the register, explain its trigger and identify every connection. Have them open the runbook using their own authorised account. Missing access should be discovered while the maker is available.
In a safe test: prove the whole journey
Use a non-production copy and agreed test records where practical. Exercise normal processing, an incomplete request and a controlled connection or permission failure. Confirm that the successor can recognise the issue and follow the escalation route. Do not disable a production identity just to demonstrate a failure.
At cutover: account for unfinished work
Agree the change window and who can pause intake. Record pending requests and running instances. Apply the approved ownership, connection and permission changes, then run a controlled end-to-end case. Match its source identifier to the work order and confirmation; a green run status alone is insufficient.
After cutover: test independence
Observe the next scheduled run or real business cycle. The successor should diagnose any exception without the original maker leading. The process owner signs off the outcome; the administrator completes access removal in line with the organisation’s leaving process.
Best practice: define the support service
A person who accepts the call
The business owner decides urgency and authorises fallback work. The technical owner maintains the flow and runbook. An administrator handles platform access, licensing and identity changes. Name deputies and agree cover for leave.
A runbook somebody has used
Include the trigger, dependencies, expected output, common errors, safe restart rules and escalation contacts. Link to the approved flow version or solution package and document configuration. An export alone is not a tested recovery plan.
Access matched to responsibility
Co-owners have substantial management access. Run-only permission serves a different purpose and is not a support role. Review access when people change jobs, and keep secrets out of handover notes. [1]
A maintained record
Add the dependency register to the leaving and role-change process. Revisit it after connector, permission or licensing changes. Make the successor drill part of accepting a business-critical flow into normal operation.
Measure independence, not the number of owners
Use critical flows with a passed successor drill ÷ all identified critical flows as a coverage measure. Define “critical” with the business: for example, whether an interruption could prevent a time-sensitive customer commitment. Keep the inventory date visible because an incomplete denominator flatters the result.
Track unresolved personal connection dependencies, time taken to restore a complete business outcome, and requests requiring manual reconciliation after a change. Record the oldest unresolved dependency as well as the count, so a persistent gap is not hidden by progress elsewhere.
For the fictional dashboard above, passing seven of twelve drills leaves five flows without demonstrated continuity. It does not mean seven flows are immune to failure. The immediate action is to prioritise the remaining flows by business consequence and give each gap an owner and a completion date.
The benefit is practical: a shorter search for the right person, a clearer recovery decision and fewer uncertain customer requests. Measure those outcomes during drills and real incidents. Do not claim avoided downtime or cash savings without an evidenced baseline.
Could your next handover pass?
Use this assessment for one named flow. Tick only statements supported by evidence. Each item contributes one point; an untested connection or recovery route remains a release blocker regardless of the score. Answers stay in this page and are not sent anywhere.
Tick the evidence you have. With JavaScript disabled, count the five checks manually; all five are needed for the review meeting.
Frequently asked questions
Does adding a co-owner make a flow independent of its maker?
No. A co-owner can help manage the flow, but connections may still use the maker’s identity. Check every trigger and action connection, the resources they access and the applicable licence before declaring the handover complete.
Can we change the owner without rebuilding the flow?
Microsoft supports an in-place ownership change for solution-aware cloud flows when the person making the change has the required privilege. A non-solution cloud flow cannot change owner in place; assess adding it to a solution where Dataverse is available, or creating a replacement.
Should every flow use a service principal?
No. Consider a service principal application user for important organisational flows, alongside connector authentication, permissions, licensing and support arrangements. Changing the flow owner alone does not remove personal dependencies in its connections.
What proves that a handover has worked?
A successor can locate the flow, explain its dependencies, process an agreed test case, handle a controlled failure and follow the recovery instructions without help from the original maker. Record the evidence and reconcile the business outcome before signing off.
Make your essential workflows easier to hand over
Start with the flow your team can least afford to lose. Smart Statistics can help review its dependencies, agree the ownership model and turn a handover document into a tested support process.