A departing employee adds a colleague as a flow owner. The colleague can open the automation, so the handover appears complete. Later, an action that reads a mailbox or updates a business system fails. The missing question was which identity the flow’s connections were still using.

For a UAE business relying on automated order updates, approvals or document routing, handing over an automation means transferring operational responsibility and checking its dependencies. Ownership of the workflow and access to each connected system need separate evidence.

Concept illustration of workflow and connection handover; not a Power Automate screenshot or an ITZ client project.

Being an owner does not replace every connection

Microsoft’s guidance on sharing cloud flows explains that owners can manage a flow but cannot change credentials belonging to a connection another owner created. It also warns that connections using a departing owner’s credentials need attention. A flow can remain present while a dependent action becomes unusable.

Use a proposed invoice-routing flow as an example. One step reads incoming documents, another writes a record to a business application and a third sends a notification. The successor must understand all three dependencies. The fact that the notification works says little about whether the write step has the correct access.

Make a dependency sheet before the account departure

For each important flow, record the business purpose, trigger, environment, responsible business owner and technical maintainer. Then list every connected service and the identity used by each connection. Keep passwords and tokens out of the sheet; document approved ownership and recovery routes instead.

  • Business access: what data the action reads or changes and who approves that scope.
  • Connection responsibility: who can maintain or replace the connection and what happens when that person leaves.
  • Failure route: who sees an error and how they determine whether a business item completed.
  • Manual fallback: how staff continue the process while automation is unavailable.
  • Evidence: a safe representative run with expected outputs checked in the destination system.

ITZ’s business process automation service can help map these operational dependencies. Plan an automation ownership handover with your most important flow, its business purpose and the systems it touches.

Choose the supported transfer route

The correct method depends on the flow type. Microsoft’s cloud-flow ownership guidance distinguishes solution-aware flows, which support an in-place owner change, from non-solution flows, which need a different route such as moving into a solution where supported or creating a copy/export and import. Check the new owner’s licensing and the environment’s requirements before scheduling the change.

Do not treat copying as a harmless rename. Plan how the replacement becomes the active automation, how the old trigger is stopped and how queued or in-progress work is handled. Maintain a clear rollback decision. The business should know which flow is authoritative so duplicate executions do not create duplicate orders or notifications.

Replace connections with approved access, then test outcomes

Have the administrator and system owners agree the supported identity model for each connector. Reconnect or replace dependencies through the platform’s supported mechanisms, using the permissions needed for the actual task. A shared password written in a handover document is not an operational ownership model.

Run a controlled sample that exercises the meaningful branches, including an exception and any approval path. Check the business output, not just a successful trigger. Confirm the destination record, intended recipient and handling of a deliberately rejected or incomplete item. Where a flow can change live records, agree safe test data and supervision before execution.

For approval-specific waiting and reassignment risks, use the Power Automate approval timeout and handover guide. For recurring execution, the scheduled-job completion monitoring guide helps define evidence beyond “the scheduler ran”.

Keep the handover connected to offboarding

Add the dependency review to the Microsoft 365 employee offboarding checklist. Agree the sequence with the account administrator; do not leave an ex-employee’s account active indefinitely because nobody has investigated its automations. Retain only the access justified by the approved transition plan.

Connector behaviour, licensing and environment policies vary. A non-personal identity is not automatically supported by every connector, and a new owner does not automatically inherit permissions in an external application. Escalate those constraints early and document the chosen fallback.

Plan Your Automation Ownership Handover

Bring ITZ an inventory of the flows involved, the planned departure date and the applications they access. We can discuss ownership, connection dependencies, safe validation and support responsibility. Plan Your Automation Ownership Handover with the article-specific enquiry form below.

Official Microsoft guidance reviewed on 27 October 2026. The invoice-routing example is illustrative, not a client case study.