Use one connection per automation, or at least per purpose. When many flows share one saved credential, a single leak exposes all of them, a single revoke breaks all of them, and nobody can tell which flow did what. Separate connections make each problem small and traceable.
The shared connection trap
It starts reasonably. Someone connects the company's CRM to the automation tool, and every new flow reuses that connection because it is already there. A year later, twenty flows use it. The connection holds broad access, because the first flow needed broad access. Fifteen of the twenty only read one object.
Microsoft's documentation defines a connection as a saved credential stored in the environment that hosts the app or flow. That makes each connection a standing key, so the question becomes how many flows hold the same key.
What changes when you split
| Situation | One shared connection | One per automation |
|---|---|---|
| A credential leaks | All twenty flows exposed | One flow exposed |
| You revoke it | All twenty break | One breaks |
| An audit asks who changed a record | Everything looks the same | The connection name shows the flow |
| You want least privilege | Must grant the union of all needs | Grant each flow its own minimum |
| An owner leaves | Unclear which flows are affected | Each connection has one owner |
How to split without a fire drill
- Export the list of flows and the connections they use.
- Group flows by what they actually do with the connection: read only, write one object, send messages.
- Create a new connection for each group, with the narrowest permissions, using a service account.
- Name each connection with the flow, the system and the owner.
- Move flows over one at a time, and test each.
- Remove the old shared connection when no flow uses it, and revoke the grant at the provider.
- Set a rule: new flows must create their own connection, and reuse requires owner approval.
Governance helpers
Low-code platforms offer data policies that group connectors and block some of them. Microsoft's documentation notes that when a policy blocks a connector, affected resources can be suspended and connections disabled, with enforcement usually in about an hour and up to 24 hours at most. Use those policies to stop the highest risk connectors, and rely on separate connections to limit the rest.
Trade-offs
More connections means more to track. The register is the answer: a row per connection with owner, scope and review date. If that feels heavy, start with the connections that reach the most sensitive data.
Quick check
Is it ever fine to share a connection?
Yes, for flows with the same purpose, owner and permission need. Share by purpose, not by convenience.
How do I find which flows use a connection?
Most platforms list a connection's dependent flows. If yours does not, search flow definitions by connector name and keep that result in the register.
Safeguard's asset discovery and policies can help you see how many systems share the same access. Try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
