When the flow leaves too: keeping Power Automate reliable in your SME

Every Monday, a list of open orders appears in a Teams channel. New enquiries move from a form into a register, an approval reaches the right person, and the customer receives a message. Nobody calls it a business application. It is “just a flow” someone built last year.

Then that person leaves. Their account is disabled and their licences are tidied up. A few days later, sales asks why no new enquiries are arriving. The automation was small. Its importance no longer is.

This is a fictional example, but it raises a useful question for any SME: which workflows would you miss if their creator disappeared tomorrow? Power Automate makes getting started easy. Reliable operation still needs deliberate organisation. Our position is straightforward: once other people depend on an outcome, the flow needs an operational owner.

A cloud flow is a sequence in Power Automate: a trigger starts it, followed by actions and decisions. We find it helpful to distinguish four layers. This is our practical framework, not an additional Microsoft product classification.

One person may cover several roles. What matters is making those roles visible. “IT has access” does not identify who notices an invoice being assigned incorrectly. Conversely, the business owner may not know which connection needs replacing after an account change.

Do more than write down a name. Explain which decisions that person owns and who covers their absence. This already helps with three important flows; it does not require a large governance programme.

Microsoft supports additional owners who can manage and edit a flow. That is useful cover, but it does not automatically transfer connection credentials. Microsoft explicitly says to update affected connections when removing an owner.

Source: Microsoft: sharing cloud flows and modifying connections.

Our recommendation goes beyond adding another name. The deputy should be able to explain the data sources, conditions and expected result. Have them make a controlled change in a safe test configuration. A successful exercise tells you more than an entry in a permissions list.

Then work through every dependency: the incoming mailbox, SharePoint list, destination folder, approval and downstream application. Record identities and purposes, never passwords. Where does a personal permission remain? Who expects a notification that might go to an obsolete address? These modest details determine whether a handover actually works.

Microsoft supports changing the primary owner of a solution-aware flow. A solution packages related Power Platform components for management. For an ordinary flow outside a solution, changing ownership between user accounts in place is not supported. Microsoft describes adding it to a solution where Dataverse is available, or creating a new flow through copying or export and import.

Source: Microsoft: changing a cloud flow owner.

For planning purposes, check the starting point before the person's final day. A copy can introduce new dependencies. We recommend a planned cutover with test inputs, a recorded switch time and a rollback option. In particular, check that two live workflows will not process the same request during the transition.

Deal explicitly with work already in progress. Who takes over a pending approval? Which records have already been processed? Where should the replacement start? Successfully saving a flow does not answer those questions. Business acceptance should demonstrate that requests are neither lost nor answered twice.

Power Automate also supports a service principal as the owner of important flows. This is an application identity rather than a personal user account. Microsoft presents it as a way to separate ownership from an individual's employment lifecycle. The actual connections and licensing still need to support the design.

Source: Microsoft: service principal owned flows.

This is not a reason to rebuild every small helper immediately. A technical identity also needs accountable people, controlled permissions and lifecycle management. A widely shared password for a supposed automation account would not be a convincing answer.

Choose according to business impact. A personal notification about a new file can be organised more simply than the intake of every service request. For the latter, design a durable model with your IT team. Check how authentication actually works for each connector. Flow ownership and the identity used to access data are separate questions.

The Microsoft documentation checked on 21 October 2026 describes options for premium service principal owned flows including a Process licence or a designated, sufficiently licensed user. The user option has prerequisites, including co-ownership and a Dataverse environment. Entitlements included with Microsoft 365 do not automatically cover premium features.

Source: Microsoft: assigning a user licence to a service principal owned flow.

Our advice is to record the actual licensing basis of each important workflow. Recheck it when accounts, connectors or capabilities change. Technical ownership does not automatically remove every dependency on an individual's licence.

Ask your implementation partner for an understandable answer covering your specific workflow. What recurring costs arise? Which prerequisite disappears when someone leaves? What alternative is available? “It is all included in Microsoft 365” is too vague for an operational decision. We deliberately give no prices here: the relevant factors are the actual features and an appropriate current offer.

A workflow can succeed technically while notifying the wrong person. It might create a record without a crucial field. Or it might never start even though new requests are waiting. We therefore recommend two checks: did the automation run, and did the expected business result appear?

For a daily enquiry transfer, the business check could be that incoming requests on a working day have corresponding processing evidence by an agreed time. A named person investigates any mismatch. This is a proposed control, not an automatic Power Automate guarantee.

An important flow needs someone who notices its absence. Collecting error messages alone is not enough.

Arrange alerts so that a deputy receives them too. Where practical, the second alerting route should not depend on the same failing workflow. For critical intake processes, a regular reconciliation between source and destination can make a substantial difference.

Also decide what may happen after an error. Restarting a workflow could send another customer message or create a duplicate order. Use a unique transaction reference and check which steps really completed before retrying. Implementation depends on the connected systems, but the question belongs in every acceptance review.

Microsoft lists 30 days of retention for regular run history. A single execution also has a general 30-day duration limit, including pending approvals. This does not establish identical behaviour for every specialist configuration; it is the documented baseline against which to check your own workflow.

Source: Microsoft: duration, retention and other limits.

Our conclusion is that a business approval lasting months should not accidentally be designed as one continuously waiting run. Nor should run history substitute for a deliberate business record. Decide which evidence the process needs and where it belongs.

Do not keep every form and email payload just in case. A transaction reference, timestamp, status and error category may be more useful operationally than a complete confidential message. The process should determine the necessary detail and retention. More data does not automatically make an automation easier to operate.

Start with the three workflows whose absence other people would notice first. Ask sales, the back office and the people building their own flows. A conversation with central IT alone will not necessarily uncover every helper that daily work now relies on.

For each one, begin with a short operational note: purpose, environment, flow link, business owner, technical deputy, connections, licensing basis, expected outcome and outage procedure. Add the date of the last successful handover exercise. Make it specific enough for a second person to act.

Choose one flow for a controlled exercise. In an appropriate test configuration, try a missing input, a rejected approval and an interrupted connection. Use test data rather than real customer messages. Check who receives the error and how work continues, not merely whether an error appears.

Finally, agree a simple rule for new automation: anyone putting a workflow into production for others identifies ownership, cover and a verifiable success condition. For a modest improvement, this should take minutes. Business-critical workflows deserve a more thorough review. Effort should match the dependency rather than the number of boxes in the designer.

Power Automate can remove considerable repetitive work from an SME. Its value often grows faster than awareness of the company's dependence on it. That is why reviewing existing flows is worthwhile before a departure or outage forces the issue.

Our clear recommendation is to turn the most important helpers into deliberately managed workflows. You do not need a thick manual. You need understandable access, suitable licensing, a practised deputy and a check on the actual outcome. That turns “Someone built it a while ago” into a process the team can rely on.