If you've spent any meaningful time building Copilot Studio agents that call Power Automate flows, you've probably met the Connection Manager popup. It shows up at the worst time, asking your end users to grant consent, pick a connection, or — in the most fun version — handing them a red banner that says "Unable to provision connection" and walking off whistling.
The Connection Manager isn't broken. It's doing exactly what it's configured to do. The problem is that "how it's configured" involves two settings that look almost identical, sit on the same page, and govern very different things. Get them out of sync and you'll see behavior that flat-out contradicts the documentation you just read.
This post is a tour of those two settings — Plan and Run-only user binding — what each one actually controls, the four configurations they produce, and which combination silently runs your agent flow under the maker's identity (no consent prompts, no per-user licensing, no red banners). Plus the caveat nobody talks about: even the "good" configuration breaks the day the maker leaves the company.
The setup
The customer's architecture is one most teams will eventually land on:
- A Copilot Studio agent.
- A Power Automate flow used as a tool.
- The flow calls a Custom Connector that wraps Azure AI Search with an API key.
The goal: end users (employees) ask the agent a question, the agent calls the flow, the flow calls the search index, the agent paraphrases the answer back. Pretty standard "knowledge agent" pattern.
The constraint: the agent builder didn't want every employee to need a premium Power Platform license to talk to the agent. Reasonable. They'd already paid for Copilot Studio for the builder; they didn't want to license everyone in the org just so the bot could answer questions about onboarding.
So they did what the documentation suggested. They flipped the flow's plan to Copilot Studio. And they tested.
And the test worked. For the builder.
Then a colleague tested. And the agent slammed the door with a red banner: "Unable to provision connection."
Why Custom Connectors are different
The first thing worth saying out loud: Custom Connectors are premium connectors. A lot of the actions you'd use inside a Copilot Studio agent flow — HTTP, Dataverse, AI Builder — are not premium and don't make end users need a license to invoke them through the agent. Custom Connectors are different. The moment one shows up in the call path, the licensing model for invoking users is on the table.
This is also why "just call the search REST API with HTTP" (which is what we'd recommend for a service-principal pattern) sidesteps a lot of this drama. But the customer had already invested in a Custom Connector for developer ergonomics, so the question wasn't "should you ever use one" — it was "how do you make this one not bite users who shouldn't need a license."
The plot twist: there are two settings, not one
This is the part the documentation does not make obvious, and it's the entire reason the customer's plan flip didn't behave the way they expected.
When a premium connector is used in an agent flow, two independent settings govern its behavior. Both live on the flow's details page. Both default to values that disagree with what most builders actually want. And the names are similar enough that it's easy to read one and assume you've handled the other.
Setting 1 — the flow's Plan. Found at: flow details → Edit → Plan.
- Power Automate — invocations are billed against each end user's per-user license. End users need a premium-eligible SKU.
- Copilot Studio — invocations are billed against the maker's Copilot Studio messages/credits, or against environment-level Pay-As-You-Go capacity. End users do not need a per-user premium SKU.
This setting is about who pays.
Setting 2 — the Run-only user → connection binding. Found at: flow details → Run only users → Edit → per-connection dropdown.
- Provided by run-only user — at invocation time, the agent presents a Connection Manager popup and a consent window. Each user must select an existing shared connection or create a new one. A per-user connection reference gets created.
- Use this connection (<maker's connection name>) — at invocation time, the flow runs under the maker's connection. No popup. No consent. No per-user connection reference.
This setting is about who the flow runs as.
Plan controls billing. Run-only user binding controls invocation identity. They are independent. Setting Plan = Copilot Studio while leaving the binding at "Provided by run-only user" gets you the Copilot Studio billing model AND the per-user consent UX AND the per-user license requirement. Worst of all worlds.
This is exactly what the customer had configured. Their Plan was right. Their binding was the default. The default is wrong for the goal.
What the end user actually sees (and what's happening underneath)
When the binding is set to "Provided by run-only user" and an end user invokes the agent for the first time, here's what they get — and what each click is doing behind the scenes. Worth understanding even if you plan to never expose your users to it, because you'll spend a fair bit of time looking at this same UI yourself while testing.
Step 1 — the Connection Manager popup. The agent pauses mid-conversation and surfaces a card titled something like "Connection Manager" or "Open connection manager." It lists every connection the underlying flow needs (one per connector — so a flow that calls Azure AI Search and SharePoint will list two). For each one, the user sees a dropdown and the option to "Create new."
Step 2 — the dropdown's contents. What the user sees in that dropdown is not "every connection in the tenant." It's "every connection of this connector type that this user has access to." Sources can include:
- Connections the user created themselves (any time they previously consented to this connector for any flow or app).
- Connections explicitly shared with the user by another maker — typically the agent's builder — with a CanView role on the connection. This is the "shared connection" path.
- Nothing, if neither of the above applies. In that case the dropdown is empty and the only choice is Create new.
If the maker shared their connection with the user (CanView), it appears in this dropdown by name. Selecting it tells the platform "use this connection when this user runs this flow." Note: even on a maker-shared connection, the API key (or whatever credential the connector uses) is never displayed to the user. CanView lets them invoke through the connection, not read its secrets.
Step 3 — Create new (the consent path). If the user clicks Create new, the platform launches the connector's configured authentication flow. For an OAuth connector like SharePoint or Outlook this is the familiar Microsoft sign-in window asking the user to grant the connector permission to act on their behalf. For an API-key Custom Connector — exactly the scenario that drives most of this post — the user is asked to paste an API key. Most end users have no idea what that means, and shouldn't.
Step 4 — what gets created. If the user successfully consents (or successfully selects a shared connection), the platform creates a connection reference for that user against that flow. From this point on, the agent invokes the flow using that reference, and the popup never appears again for that user — until something invalidates the reference (the underlying connection is deleted, the user's consent is revoked, the API key rotates, the maker un-shares).
Step 5 — or, the red banner. If the user has no premium connector entitlement on their license, the platform refuses to provision the new connection reference and surfaces "Unable to provision connection." The dropdown's "Create new" path is effectively disabled, and the only escape hatch is for the maker to share an existing connection with the user (which uses CanView, not the user's own license — but the user still won't have the entitlement to create their own).
Connector vs Connection vs Connection Reference
Three terms that get used interchangeably in conversation and never should be. Most of the confusion in this entire problem space evaporates once you separate them.
| Term | What it is | Scope | Owned by |
|---|---|---|---|
| Connector | The definition — the contract. A schema of operations, parameters, and an authentication scheme (API key / OAuth / etc.). For a Custom Connector, this is the thing you build once with a Swagger doc. | Environment-wide | A maker, but functionally a tenant asset |
| Connection | An instance of the connector with credentials filled in. "Here is a Custom Connector definition + here is the API key to use." The thing that actually holds the secret. | User-scoped (you can share it with CanView) | The user who created it |
| Connection Reference | A pointer from a flow (or app) to a specific connection — i.e. "when this flow runs as this user, use connection X." The Run-only user → connection binding setting we keep talking about is literally just choosing which connection reference the flow should use at invocation time. | Per-flow, per-user | The flow + the invoking user |
So the chain at runtime, in order of resolution:
Agent → calls a flow → flow needs a connector → flow looks up its connection reference for the invoking user → reference points to a connection → connection holds the credential → credential is sent to the downstream service.
Maker-bound mode skips the per-user reference: the flow points to a fixed connection (the maker's), and every invocation uses that same connection regardless of who triggered the agent. That's the magic that removes the popup and the licensing requirement — there's no per-user reference to provision, so there's nothing to fail.
The four configurations and what each one produces
Once you see them as two settings, the matrix writes itself.
| Plan | Run-only user binding | End-user experience | Per-user license required |
|---|---|---|---|
| Power Automate | Provided by run-only user | Consent + Connection Manager. User picks or creates a connection. Red banner if unlicensed. | Yes |
| Power Automate | Use this connection (maker) | Per-user plan still attaches licensing to the invoking user. Practically the same friction as row 1. | Yes |
| Copilot Studio | Provided by run-only user | Consent + Connection Manager — exactly like the Power Automate plan. Red banner for unlicensed users. (The trap.) | Yes |
| Copilot Studio | Use this connection (maker) | Silent. No popup. No consent. No per-user reference. The agent just works. | No |
Only the bottom row gives you the experience most builders expect when they hear "Copilot Studio plan." The third row — the one that highlights itself in caution-yellow up there — is where unsuspecting builders land by default and where the customer's "user 2" landed.
I tested all four in a demo tenant with a stripped-license user (Microsoft 365 E5 + Teams + Power Automate Free only — no Copilot, no Copilot Studio User License, no Power Apps developer entitlement). The bottom row produces a perfectly silent invocation in both Microsoft 365 Copilot Chat and Microsoft Teams. No banner. No prompt. The agent just answers. The third row produces the red banner reliably.
Corrective Path
If you're in the trap and want to climb out, this is the sequence:
- Set Plan = Copilot Studio. Flow details → Edit → Plan. (Heads up — the plan flip is irreversible. You can't go back from Copilot Studio to Power Automate on the same flow without rebuilding it. Make a copy first if you're not sure.)
- Set the Run-only user binding to "Use this connection (<maker's connection name>)" for every connection in the flow. Flow details → Run only users → Edit → per-connection dropdown.
- Share the maker's connection with the audience that should be able to use the agent. Power Platform → Connections → pick the connection → Share → add users with CanView. CanView is enough for invocation; it doesn't expose the API key.
- Republish the agent in Copilot Studio.
After step 4, your unlicensed user should invoke the agent with no Connection Manager popup, no consent window, no red banner.
If they don't — check that you actually clicked Republish. I've forgotten that step more times than I will admit in writing.
The caveat: this doesn't solve "the maker leaves"
This is the bit that catches the second wave of builders, usually about three months after the first crisis is over. Read carefully.
The Copilot Studio plan + maker-bound binding combo solves the licensing problem. It does not solve the ownership problem. The connection is still owned by a human. If that human's account is disabled, the connection orphans, and the agent fails for everyone — exactly the same way it would have failed under the old per-user pattern.
The durable answer is to back the connection with a non-human identity. Two paths, both better than the API key pattern in production:
- Service Principal — refactor the Custom Connector's authentication scheme from API key to OAuth 2.0 client credentials, backed by an Entra app registration. Store the secret in Key Vault and rotate it on whatever cadence your security team likes. The role assignment on the search service is bound to the SP's object ID, not to any credential, so rotation is a non-event.
- Managed Identity — if you have Managed Environments enabled and your downstream service supports MI auth (Azure AI Search does), this is the lowest-secret-management path you can take. No keys to rotate. Ever.
The combination that satisfies all three customer requirements — no per-user licensing, no consent friction, no maker-departure risk — is:
Plan = Copilot Studio + Run-only user = maker-bound + Connection backed by SP or MI.
That's the configuration I recommend if you're starting fresh, and the migration target if you're already invested in a Custom Connector with an API key.
A few things I learned the hard way during this
- "Plan = Copilot Studio" is not the same as "Copilot Studio billing only." Read the Run-only user dropdown before you ship.
- The plan flip is one-way. If you change a flow's plan from Power Automate to Copilot Studio and decide a week later you want it back the way it was, the answer is "delete and rebuild." Save a copy if you're piloting.
- Sharing the maker's connection populates the Connection Manager dropdown. If you're stuck on the per-user plan for some reason, share the connection (CanView) with the user. They'll see the maker's connection in the dropdown instead of being asked for the raw API key.
- API-key custom connector secrets never echo back in the UI. When you click Edit on a connection and the API Key field looks blank, that's normal. Don't paste the key back in unless you actually intend to rotate it — doing so can trigger a fresh provisioning handshake on the APIM gateway, which is sometimes useful as a forced refresh and sometimes the source of a "ServiceTemporarilyUnavailable" while it reconciles.
- Republish, then test in a fresh chat. Both Microsoft 365 Copilot and Microsoft Teams cache earlier conversation context aggressively. A successful old reply isn't proof that the new configuration works — start a brand-new conversation when validating.
Useful resources
- Microsoft Learn — Use connectors in Copilot Studio: https://learn.microsoft.com/en-us/microsoft-copilot-studio/copilot-connector-actions
- Microsoft Learn — Power Automate flow plans (Copilot Studio vs Power Automate): https://learn.microsoft.com/en-us/power-automate/flow-types
- Microsoft Learn — Custom connectors overview: https://learn.microsoft.com/en-us/connectors/custom-connectors/
- Microsoft Learn — Service Principal authentication for OAuth-based connectors: https://learn.microsoft.com/en-us/connectors/custom-connectors/connection-parameters
- Power Platform Admin Center: https://admin.powerplatform.microsoft.com/
If you've hit the red banner with Plan = Copilot Studio and felt gaslit by the documentation, you weren't wrong. The setting works. There just happens to be a second one quietly running the show. Now you know about both.