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.

Users get "Unable to provision connection" prompts instead of answers

Mitigatedsince 8 July 2026

Last verified

Details & related

Assessment

Confidence
CorroboratedMultiple independent sources describe the same behaviour.
Severity
Blocking
Typical time lost
Hours

Identification

Knowledge & groundingAuth & identityAll channels

Verification & changes

  1. Verified

    Doc check by human: Dossier sections A7/C3 and connector docs re-read during seed migration; connection prompts still reported despite service-principal setup.

  2. Change

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

  3. Change

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

Related

Are you in the right place?

  • You connected Azure SQL or another knowledge source that needs its own connection.
  • In your own tests as maker, everything works.
  • End users get "Unable to provision connection" instead of an answer.
  • Or users see a consent prompt mentioning FederatedKnowledgeSearchOperation.
  • You configured a service principal and expected users to see nothing.

If instead answers arrive with stale or missing SQL data → live-data expectations, not this record (record planned). If instead knowledge returns nothing without any prompt → see Knowledge returns nothing — and no error is shown. If instead a flow fails with permission errors → see Flow fails with the user's permission errors despite "Maker-provided credentials".

What's happening

Some knowledge types, such as Azure SQL, read data through a per-user connection. A connection stores who may query the underlying system. Often a service principal — a technical account meant to query for everyone — is configured. Community reports show users still being asked to provision, meaning create, their own connection. Users who can't complete the prompt get "Unable to provision connection" instead of answers. Others see a consent prompt for a federated knowledge search operation. It's like a canteen card every employee must still activate at a machine nobody explained.

For technicians
  • Community reports, documented as of 2026-07-08, show prompts persisting despite service-principal configuration; managed identity is recommended where available.
  • Two documented limits matter here, as of 2026-07-08.
  • Connector responses over 500 KB fail.
  • The Azure SQL connector enforces a 40-second query timeout.
  • The consent prompt names the internal operation FederatedKnowledgeSearchOperation.

How to fix it

Solution 1

Community workaround

Serve the data through an agent flow instead

  1. Create an agent flow that queries the database with a fixed maker connection.
  2. Return the result to the agent as text.
  3. Remove the knowledge source that triggered the prompts.
  4. Update the agent's instructions to use the flow for data questions.

✅ You should now see: users receive data answers without any connection prompt.

  1. Keep the flow's work within the documented limits from the technicians' section.

Solution 2

Community workaround

Review the connection's authentication setup

  1. Open the knowledge source's connection settings.
  2. Check whether managed identity is available for your database; community reports recommend it over a service principal.
  3. Test with a real end-user account, not your maker account.

✅ You should now see: a test user reaching answers without the provisioning error.

Check that it worked

Ask a data question as a real end user in the published channel. Expected: an answer arrives, with no connection or consent prompt.

If it didn't work

  • You tested with your maker account. Your own connections mask the problem; always retest with an end-user account.
  • The channel still serves the old configuration. See Teams answers with an old version of your agent.
  • The flow hits a limit. Responses over 500 KB or queries over 40 seconds fail, documented as of 2026-07-08.
  • Expectations, not errors. If data arrives but is stale, that is separate (record planned).

Prevent it next time

  • Adopt the rule "live data comes from a flow, not from knowledge" when you plan data access.
  • Test every new data source with a genuine end-user account before rollout.

Evidence

  • MVP blogmatthewdevaney.com

    Comment threads on this practitioner post report end users receiving 'Unable to provision connection' errors despite service-principal authentication being configured.

  • Official documentationlearn.microsoft.com

    The Azure SQL connector documentation sets a 40-second query timeout and describes the connector's authentication requirements.

  • Official documentationlearn.microsoft.com

    Documents that connector responses over 500 KB fail, a limit that constrains data retrieved through connections.