[Bug] Cannot use multiple HTTP with Microsoft Entra ID (preauthorized) connections in the same Code App

[GBency]

Describe the bug

It is not possible to reliably use two connections of the same connector type HTTP with Microsoft Entra ID (preauthorized) (shared_webcontents) in a single Power Apps Code Apps project.

Even when two connectionReferences are configured with different sharedConnectionId values, runtime requests are effectively routed through one connection, causing one integration path to fail (or use the wrong connection).

This blocks multi-scope scenarios such as:

• SharePoint + Power Automate
• SharePoint + Microsoft Graph
• Power Automate + Microsoft Graph

Steps to Reproduce

1. Create a Power Apps Code Apps project.
2. Add two connection references in power.config.json for shared_webcontents, each with a different sharedConnectionId.
3. Use both references in the app for different targets (for example SharePoint and Power Automate).
4. Trigger InvokeHttp requests for both targets.
5. Inspect request path/runtime behavior and observe that one connection is consistently used.

Expected behavior

Both connector connections should be independently usable in the same app, with stable routing per connection reference/data source.

Actual behavior

Requests are effectively bound to one connection for shared_webcontents; the second integration path is routed with the wrong connection.

Screenshots or Error Messages

Example of request path observed for wrong routing:
/connectors/runtime/invoke/scaleGroups/firstrelease/shards/06/apis/webcontents/connections/<connection-id>/codeless/InvokeHttp

In our case, one scenario expected ba7a5eba6dc94b1e82c3cba632f1868b but runtime used 48e70e68bd8e4bcfbc18077433c2a0be (or vice versa depending on mapping).

Environment information

• Framework, build tool or relevant package used: React + Vite (Power Apps Code Apps)
• Any connection/components: Dataverse, Office 365 Users, HTTP with Microsoft Entra ID (preauthorized)
• OS: Windows

Additional context

Workaround found

We manually created a dedicated logical data source alias per target, for example:

• webcontents (one connection)
• webcontents_flow (second connection)

Then we:

1. Mapped aliases in power.config.json under connectionReferences[].dataSources.
2. Added matching datasource entries in .power/schemas/appschemas/dataSourcesInfo.ts.
3. Routed calls in app code by datasource alias (SPO alias vs Flow/Graph alias).

What this workaround enables

With this setup we can:

• Use SharePoint APIs with full user context (delegated context of the signed-in user).
• Execute authenticated HTTP calls to Power Automate endpoints.
• Execute authenticated HTTP calls to Microsoft Graph.

Limitation of workaround

This workaround is not durable:

• It gets reset/overwritten when adding a new datasource (for example after pac code add-data-source).
• Manual alias/schema changes must be reapplied.

Requested fix

Please support stable multi-connection usage for shared_webcontents by:

1. Generating and preserving distinct datasource aliases per connection reference.
2. Keeping mappings stable across pac code add-data-source and regeneration.
3. Documenting the recommended approach for multi-scope usage (SharePoint, Power Automate, Graph).

[eschavez]

Thanks for the detailed report and for tracking down the workaround — this is genuinely helpful context.

You're right that this is a bug. When multiple \shared_webcontents\ (HTTP with Microsoft Entra ID) connections are present, codegen doesn't generate distinct aliases per connection — they collapse to a single entry, which causes the runtime to route all requests through one connection. Your manual alias approach is the correct workaround for now.

The downside, as you've found, is that \pac code add-data-source\ regenerates the file and wipes it. Until a fix lands, you'll need to reapply the alias split after each data source operation.

We'll track this in the product team backlog. I'll update this issue when there's a fix or a more durable workaround available.