Copilot Studio Workflow — connections owned by a service account don't work when a different user opens it. Why, and is there a fix?

Question

Copilot Studio Workflow — connections owned by a service account don't work when a different user opens it. Why, and is there a fix?

BATES Jack (EXT) 40

I built a Workflow (Copilot Studio's newer autonomous/event-driven flow type, not classic agent flows or Power Automate cloud flows). All connections in it (SharePoint, Dataverse, Outlook, etc.) are authenticated under a dedicated service account, not my personal login.

When a colleague (who has Environment Maker access, not the service account) opens this Workflow to view/edit it, none of the connections work for him — he can't test or run any of the connector actions, and it behaves as if no connection exists at all for his session.

Is this expected behavior — i.e. do Workflow connections not support "maker/author" credentials the way classic Copilot Studio connections apparently can (per the "agent author authentication vs user authentication" note in the general Connections docs)? Or is there a way to actually share/grant access to a connection owned by another identity so a different maker can use it without creating their own?

Trying to understand if this is a hard platform limitation for Workflows specifically, or if I'm missing a sharing/permission step somewhere.

0 comments

Answer accepted by question author

0 additional answers

Your answer

Answer 1

Hello BATES Jack (EXT) •
What you're seeing is generally expected. In the new Copilot Studio Workflows experience, connections are tied to the identity that created/authenticated them. Giving another user Environment Maker access allows them to open and edit the Workflow, but it does not automatically give them access to use the original maker's authenticated connections.

As a result, when your colleague opens the Workflow, SharePoint, Dataverse, Outlook, and other connector actions may appear disconnected or unusable until they create or authenticate their own connections. Sharing the Workflow is not the same as sharing the underlying connection credentials.

If all connections were created using a dedicated service account, there is currently no general "author credential sharing" model that lets other makers seamlessly edit and test the Workflow using that service account's connections. In practice, each maker usually needs their own connections, unless a connector specifically supports a shared authentication pattern.

So based on your description, this sounds more like a current platform limitation/design behavior around connection ownership rather than a missing Environment Maker permission or overlooked sharing step.
https://learn.microsoft.com/en-us/microsoft-copilot-studio/authoring-connections