[Bug] One unresolvable connection reference discards the entire appConnections map, so every flow call fails citing an unrelated flow

Start by comparing successful and failing launch responses, especially appConnections, with the per-user shared_logicflows listings from the admin connections API. Trace the SDK path through node_modules/@microsoft/power-apps/dist/internal/data/core/data/executors/connectorDataOperationExecutor.js and the host loadAppConnectionsAsync_v2 entry point. Done means identifying why shared users receive incomplete maps and defining a verified fix for flow calls.

Describe the bug

In a published Code App shared with several users, some non-owner users get
Execute operation failure: Connection reference not found: <dataSourceName> on every Power
Automate flow call, while other non-owner users of the same app, in the same environment, shared at
the same moment by the same person, work correctly. Reads through the app's SQL Server connection
work for everybody. Only flow calls fail.

The launch response for a failing user carries an appConnections collection with only the 3
non-flow connections. All 16 shared_logicflows entries are absent, so
connectorDataOperationExecutor._getConnectionReference throws client-side and nothing reaches
Power Automate.

The state is per user and per app. It has survived republishing the app, a solution promotion, hard
refresh, cache clearing, private browsing, a run-only permission grant on the flow, and a full
removal and re-grant of the user's app permission with a 24 hour wait before the next launch. Three
of six tested users in our production environment are affected, 12+ days after the share.

The map a user receives has no relationship to the shared_logicflows connections that user already
owns, tested in both directions and detailed under Additional context.

Steps to Reproduce

This does not reproduce on demand. Whether a given user is affected appears to be decided once, at
that user's first launch, and we have not found the input that decides it. What we can give is the
shape that produced it, twice, in two environments:

1. Build a Code App (React + Vite) that declares Power Automate flows as data sources. Ours declares
   19 connection references, 16 of them shared_logicflows.
2. Publish it, with the app and its flows in the same managed solution, connection references
   included.
3. Share the published app with several users at once, as CanView.
4. Have each user open the app and attempt any flow-backed write.
5. Some users save normally. Others get Connection reference not found naming the data source, on
   every flow they touch, permanently.

To tell the two groups apart without waiting for a user to hit the error, read the environment's
per-user flow connections as an admin:

GET https://api.powerapps.com/providers/Microsoft.PowerApps/scopes/admin/environments/<env>/apis/shared_logicflows/connections?api-version=2016-11-01

A user with connections to flows that only this app has ever used will save. A user with none of
them, who has launched, will throw. That has matched the outcome 6 times out of 6 for us.

Expected behavior

Every user the app is shared with receives the same appConnections map from launch, so a flow
data source declared in the published app resolves for all of them, and flow-backed writes work for
shared users the way they work for the maker.

Actual behavior

The failing user's launch response returns appConnections with only the non-flow connections.
The SDK then throws client-side on the first flow call, before any request reaches Power Automate,
so the flow shows no run and platform telemetry reports the session as healthy.

The condition is permanent for that user and that app. Nothing we can do from the maker or tenant
admin side has repaired a user once they are in it.

Screenshots or Error Messages

Verbatim, as the user sees it:

Execute operation failure: Connection reference not found: savedata_job_dates

The same string appears for every flow data source the user touches, naming that data source.
Platform telemetry for the session reports FailedDataRequests: 0 and ClientState: healthy
throughout, so the failure is invisible in the health data.

Raw launch response bodies and HAR captures are not attached on purpose: every logicflows
connection in them carries a workFlowCallbackUri with a live sig= that can invoke the flow.
Happy to share scrubbed captures privately.

Environment information

• Framework, build tool or relevant package used: React + Vite. @microsoft/power-apps-cli
  1.0.0, @microsoft/power-apps (SDK) 1.2.5. Web player 3.26083.3, observed 2026-09-02.
• Any connection/components: 19 connection references, 16 shared_logicflows (Power Automate
  cloud flows) and 3 non-flow, including SQL Server over an on-premises data gateway. The 16 flows
  live in the same managed solution as the app, with connection references included. Reads go
  through the SQL connection and are unaffected; only the flow calls fail.
• Reproduced in three environments (dev, staging, production) with the same user provisioning
  correctly in one and failing in the other two.

Additional context

Where it throws

1. The generated service calls getClient(dataSourcesInfo) then executeAsync with
   tableName = '<dataSourceName>'.
2. connectorDataOperationExecutor._getReferences fetches the connection map once per page life
   through RuntimeMetadataClient.getAppConnectionConfigsAsync, which asks the host plugin
   AppPowerAppsClientPlugin.loadAppConnectionsAsync_v2. The result is keyed by data-source name.
3. _getConnectionReference(tableName) throws ConnectionReferenceNotFound when the key is
   absent, at
   node_modules/@microsoft/power-apps/dist/internal/data/core/data/executors/connectorDataOperationExecutor.js:393.
4. The host builds that map from the launch response's appConnections.

So the SDK is behaving correctly. The question is why the platform hands a failing user a map
with no shared_logicflows entries.

The launch diff

Same app, same environment, same day, GET .../powerapps/apps/<appId>/launch?api-version=2:

Caller	appConnections entries	shared_logicflows among them
Owner / maker	19	16
Affected shared user	3	0

The manifest is identical between the two callers: same 19 connection references, same
appEntitlementDetails, same executionRestrictions, same empty userAppResourceConsent and
authorizationReferences, same premium licence flag (canUsePremiumApis: true).

The discriminator we found

Two of the 16 flows were created in August 2026 and have never belonged to any other app, so a
per-user shared_logicflows connection to either one can only have been minted by the Code App
player. Reading the admin-scope connections listing for the environment
(GET .../scopes/admin/environments/<env>/apis/shared_logicflows/connections) separates the
users cleanly:

User	Connections to the two new flows	Result in the app
A (owner)	both, created 6 minutes after the production publish	works
B	both, created 25 h after the share	works
C	both, created 3.5 d after the share	works
D	none, 12 d after the share	fails
E	none, 12 d after the share	fails
F	none, 12 d after the share	fails
G, H	none, have never launched the app	untested

Six out of six: every user holding those connections saves, every user without them throws. All
eight users were shared on the app in the same operation.

The same user (E) provisions correctly in our development environment. The player minted six
missing connections for them there at 2026-07-24 16:47:33Z to 16:47:36Z, the day after they were
shared on the dev copy of the app. That user then fails in staging and in production. So the
account itself provisions correctly when the first-launch step runs.

Possession of a connection is neither necessary nor sufficient

appConnections is not assembled from the connections the calling user already holds. We tested
both directions and both came back negative.

• Not sufficient. User E has held a per-user connection to the SaveData - Job_Dates flow
  since 2023-07-17, from a legacy canvas app that uses the same flow. They still get
  Connection reference not found: savedata_job_dates. They hold 13 of the 16 flow connections
  and all 16 flow writes fail, including the 10 they hold.
• Not necessary, tested 2026-09-14. Users B and C each hold 15 of the 16, both missing the
  connection for one flow, SaveData - Job_Builders, because neither had ever exercised that
  write. We asked them to run it. User C changed a builder on a live job at 16:46Z and the save
  succeeded. User B changed it back at 17:22Z and that save succeeded too. Two users, no
  shared_logicflows connection for that flow, and the write resolves anyway.

So a working user's map carries an entry for a flow they hold no connection to, and a failing
user's map carries nothing for flows they do hold connections to. The map appears to be
provisioned wholesale for the app at first launch and to have no relationship to the caller's
existing connections in either direction.

One consequence worth stating, because it may save someone else the same dead end: dropping the
flows a user does not hold from the build cannot be a workaround. The map is not per-flow.

A first launch a day after the share is not enough on its own

Our leading hypothesis was that a first launch made too soon after the share, before the grant
propagates, is what makes provisioning skip. The timing data does not support it as a sufficient
explanation:

User	Gap between share and first launch	Provisioned
B	+25 h (mint timestamp, hard)	yes
C	+3.5 d (mint timestamp, hard)	yes
D	~+1 d (self-reported first open, the day after the share)	no
E, staging	+9 min (from a HAR)	no
E, dev	+1 d	yes

User D's figure is a recollection rather than an instrument, and we treat recollections cautiously.
Taken with the reset run below, where an observed launch 24 h 42 min after a fresh share provisioned
nothing, the delay does not look like the whole story.

The remove-and-re-share reset does not repair it (controlled run, negative)

Issue #402 reports a persistent per-user app binding created at first consent, cleared only by
deleting and re-granting the user's app permission. We ran that as a controlled experiment in our
staging environment and it did not repair the user.

Step	Time (UTC)	Source
Baseline listing: subject 0/16, owner 16/16	2026-09-08 17:43:00Z	admin connections API
App share removed, only the owner remains	confirmed 2026-09-08 17:59:09Z	app permissions API
Subject signs out hard, before the re-grant	2026-09-08, before 18:23Z	subject confirmed
Share re-added as CanView	2026-09-08 18:23:33.450Z	permissions API createdOn
Subject's first launch, through the Power Apps launcher, fresh InPrivate window	2026-09-09 19:00 to 19:10Z, best estimate 19:05Z	observed live by the maker on a Teams call
Post-launch listing: subject 0/16, unchanged	2026-09-11 19:05Z, 48 h after the launch	admin connections API

The gap between the re-share and the launch was 24 h 42 min, longer than any of the three
successful provisioning events we have on record. Nothing was minted.

The environment-wide control is the part worth reading twice: zero shared_logicflows
connections were created anywhere in that environment on or after 2026-09-08, for any user, by
any means. The total held steady at 120. So there is no reading in which provisioning ran and
something else swallowed the result. Nothing was attempted, or the attempt failed before it
created anything.

Ruled out (checked, with the evidence)

Candidate	Finding
Flow run-only permission	A working user has no permission on the flows at all. A failing user has CanView on one of them.
Legacy canvas app share	All eight users can reach the legacy app that uses 14 of the same flows.
Dataverse security roles	Every user has Basic User plus a custom basic role. Nobody in the production environment has App Opener, including the users who work. The working and failing users get their roles through different paths (direct, and via group teams) with no correlation to outcome.
Premium licence	canUsePremiumApis: true and the same licence id for a working and a failing user in the launch payload.
hideNavBar in the launch URL	Two links reached the testers. Users on the same link fall on both sides of the outcome.
Connection status Error / ConfigurationNeeded	Universal, present on the owner's working connections too.
Unmanaged solution layers on the flows	None. Each flow carries exactly two managed layers.
Republish / solution promotion	A promotion landed between the failure and now. It changed nothing for the affected users. The owner's connections were re-minted at publish time, which suggests a publish re-provisions the maker only.
Repeated launches over 12 days, including through the Power Apps launcher	A failing user has launched repeatedly, including from make.powerapps.com, and has never minted.

What we think is happening

The player runs a one-time per-user provisioning step at a user's first launch: it mints the
missing shared_logicflows connections for the app's flows and records what that user's
appConnections will carry. When the step completes the user gets all 19. When it is skipped or
fails, the user gets the 3 non-flow entries, and the result is persisted per user and per app, so
republishing, cache clearing, later permission grants and a share reset do not repair it.

We cannot verify that from outside, which is why we are filing this rather than working around
it.

Questions

1. Where does the platform persist the per-user, per-app state that decides which entries a
   caller's appConnections contains? Is there any supported way for a maker or a tenant admin
   to read it, or to clear it for one user?
2. Under what conditions does the first-launch provisioning step skip or fail? Is a first launch
   made shortly after the share, before the grant propagates, a known failure mode? We suspected
   it, but the timing table above does not carry it on its own: one failing user launched roughly
   a day after the share, and an observed launch 24 h 42 min after a fresh share provisioned
   nothing.
3. #402 says deleting and re-granting the user's app permission clears the binding. It did not
   here, and nothing was minted environment-wide afterwards. Is there a second store that
   survives the permission delete?
4. Is there a correlation id or a telemetry surface for the provisioning step? Platform health
   reports the sessions as clean, so we have nothing to hand a support engineer.
5. Does republishing the app re-provision shared users, or only the maker? Our evidence points at
   maker only, and confirming it either way changes what remediation is available to us.

Still outstanding on our side

• A HAR of a failing user's first launch, to show whether the player issues any
  PUT .../connectivity/apis/shared_logicflows/connections/... and with what status. No PUT at
  all would be a different finding from a failed PUT, and we do not yet know which it is.
• A fresh-share arm on a user who has never been shared on the app in that environment, to
  separate "a stuck per-user binding a re-share cannot clear" from "provisioning does not run for
  shared users here at all".

We will add both when we have them. Posting now because the negative reset result closes off the
only remediation path we had and we would rather not have others repeat it.

Related

• #323, same error string, different cause (no shared_logicflows connection in the environment
  at all, rather than per user).
• #402 (closed 2026-07-20), the closest public description of the per-user binding. This report is
  the same shape with a remedy that failed.

Identifiers

Environment ids, app ids, flow ids, per-user connection names, the two launch response bodies
and the admin connections listings are all in hand. Happy to supply them privately or through a
support ticket rather than in a public thread.

---

This investigation and write-up were done with the assistance of Claude. Every finding, timestamp
and test result here was verified and checked by me against the environments and the raw responses
before posting.

---