What it does

Three separate ways to give someone access to a cloud flow: add them as an owner, give them run-only permission, or send them a copy. They behave very differently, and the difference between the first two is the whole governance conversation.

Key facts

• An owner can view run history, start and stop the flow, edit the definition, update connection credentials, add and remove other owners, and delete the flow. That's near-total control.
• Owners can't remove the flow's creator, and they can't modify credentials on a connection another owner created.
• Run-only sharing is available for instant flows — the ones with a manual trigger. Run-only users can trigger the flow and nothing else.
• When you add a run-only user you choose whether the flow uses its embedded connection, or whether the connection is Provided by run-only user, in which case the flow acts as that user with their access.
• Connections provided by a run-only user are used only by that user. Embedded connections are used by everyone. On export, invoker-provided connections carry a RuntimeSource of invoker.
• SharePoint lists and security groups can be added as co-owners, so list or group membership grants flow access. Adding a list as co-owner isn't available in GCC High and DoD.
• Solution-aware flows support an in-place owner change. Non-solution flows don't — the owner is part of the flow identity, so you export/import, Save As or Send a copy to move it.
• Sending a copy creates an independent flow for the recipient. You can't revoke it afterwards.
• Sharing ownership of a solution flow with someone who isn't in Dataverse adds them to Dataverse automatically, but outside the default environment they don't get the Environment Maker role, so they may only be able to run it until an admin assigns a role.

When to use / skip

Default to run-only and add co-owners only when someone genuinely needs to edit. Co-ownership is the single most over-granted permission on the platform — people hand it out so a colleague can see why a flow failed, and quietly give away the ability to delete it. If the requirement is "they need to know it broke", that's an alerting problem, not a sharing problem. Send a copy is for templates and demos and nothing else, because you lose all control the moment you click it.

Configuration decisions

• Co-owner versus run-only for each flow, decided by whether the person needs to change the logic.
• Whether run-only users bring their own connection or use the embedded one — this decides whose permissions the flow actually runs with.
• Whether ownership sits with a named person, a security group, or a service principal.
• Whether the flow is solution-aware, since that determines whether ownership can ever be transferred cleanly.
• Who audits sharing, and how often. Microsoft's own guidance is periodic entitlement reviews with PowerShell.

Gotchas

• When the creator leaves, the flow keeps running if there's another active owner — but any embedded connection owned by the leaver starts failing. The flow looks alive and quietly does nothing useful.
• If there's no active owner at all, there's no ownership transfer for a non-solution flow. You copy it and rebuild, which loses run history.
• Adding a security group as co-owner means everyone in that group can delete the flow. Group membership changes then silently change who can destroy production.
• Guest users can be added as owners. That's a data governance conversation the maker almost certainly didn't have.
• Shared connections only work in the flow they were created in, which trips people expecting to reuse a connection across flows.

Consultant notes

• Get service-account or service-principal ownership agreed for anything business-critical before build, not after the first leaver. Retrofitting ownership across an estate is grim work.
• Make solution-aware the default for anything that matters, purely because it's the only path to a clean ownership change later.
• Warn the client explicitly that co-owner includes delete. Most business stakeholders assume it means "can see".
• Build the sharing audit into the client's operating rhythm — PowerShell or the CoE kit, monthly or quarterly. Sharing decay is continuous and nobody notices it happening.

---

Revisit if in-place ownership change ever arrives for non-solution flows, or if run-only gains a middle tier.