PowerLeap Logo

Copilot Studio Friction

Get notified when this record changes

One email when the status or the fix changes — double opt-in, no tracking, unsubscribe in every email.

Flow fails with the user's permission errors despite "Maker-provided credentials"

Mitigatedsince 8 July 2026

Last verified

Details & related

Assessment

Confidence
Confirmed officialConfirmed by Microsoft documentation or an official statement.
Severity
Blocking
Typical time lost
Hours

Identification

Agent flowsAll channels

Verification & changes

  1. Change

    Pipeline: new evidence from m365-roadmap — review required.

  2. Verified

    Doc check by human: CAT blog post and official flow-tool doc re-read during seed migration; the two-level credentials model is still documented.

  3. Change

    Provisionally approved by the Product Owner; external LLM quality review pending.

  4. Change

    Initial record created from the seed dossier (migration wave 1).

Related

Are you in the right place?

  • You set the flow tool's credentials to "Maker-provided credentials" in Copilot Studio.
  • The agent flow starts when the agent calls it.
  • Individual actions inside the flow fail with permission errors of the end user.
  • Everything works when you trigger the flow yourself, as the maker.

If instead users see "Unable to provision connection" prompts → see Unable to provision connection. If instead the whole call fails with FlowActionBadRequest → see Flow fails with "FlowActionBadRequest". If instead the flow never appears as a tool → see Your flow doesn't show up as a tool.

What's happening

The credentials setting on the tool governs only the call — how the agent starts the flow. Inside the flow, authentication happens on a second, separate level. Every action uses its own connection reference: a saved pointer to a login for a connector. Those references keep whatever connection they were built with — the setting does not touch them. So the flow starts under the maker's identity, but an action inside still demands the end user's permissions. Think of a visitor badge: it opens the lobby, but every office door still needs its own key. The setting hands out the badge; the door keys are configured per action, inside the flow.

For technicians

This is a two-level model: call-level credentials (the tool setting in Copilot Studio) versus action-level connection references (in the flow). Switching to "Maker-provided credentials" rewires level one only. The failures surface deep in the run history, on the specific connector actions whose connection resolves to the calling user.

How to fix it

Solution 1

Official workaround

Point the flow's connections at the maker's connections

  1. Open the agent flow in the flow designer.
  2. Open the run history and select a failed run.
  3. Note every action that failed with a permission error.
  4. For each of those actions, open its connection settings.
  5. Switch the connection to a maker-owned connection.

✅ You should now see: every action in the flow lists the maker's connection, not the end user's.

  1. Save the flow.
  2. Confirm the tool's credentials setting in Copilot Studio still reads "Maker-provided credentials".

Check that it worked

Ask a colleague or test account without permissions on the target system to trigger the flow through the published agent. Expected: the run succeeds, and the run history shows the actions using the maker's connection.

If it didn't work

  • One connection was missed. Flows often hold several connections across their actions. Recheck every action, including ones inside branches.
  • The maker's connection lacks the permission itself. The maker account needs real access to the target system. Test the flow standalone with that account.
  • The channel still runs your old agent version. Publish and propagation delay is a standard suspect. See Teams answers with an old version.
  • The tool setting flipped back. Re-open the tool in Copilot Studio and verify the credentials setting.

Prevent it next time

  • Write the two-level rule into your team docs: the tool setting governs the call, connection references govern the actions.
  • Review every connection inside a flow before sharing the agent with end users.
  • Test each new flow once with an account that has no special permissions.

Evidence

  • Microsoft statementmicrosoft.github.io

    Microsoft's CAT team states the credentials setting affects only how the agent calls the flow, while each action authenticates through its own connection reference.

  • Official documentationlearn.microsoft.com

    The official doc describes adding a flow as a tool, including the credentials configuration the flow call runs under.

  • Official documentationmicrosoft.com

    Official roadmap feature to block maker-provided credentials directly addresses the root cause of the existing record where flows fail with permission errors despite using maker-provided credentials.