Flow Connection References – Caller Does Not Have Permission for Connection

The Problem

When attempting to activate a flow, I get the following error:

"error" : {"code" : "ConnectionAuthorizationFailed", "message" : "The caller with object id '<guid>' does not have permission for connection '/providers/Microsoft.PowerApps/apis/shared_commondataserviceforapps/connections/shared-commondataser- <guid> under Api 'shared_commondataserviceforapps' ."}

• This may also appear with any connections, such as shared_commondataserviceforapps, shared_azureblob, shared_sql, etc.
• Checking to confirm if the caller is the current user via the api https://myorgurl.crm.dynamics.com/api/data/v9.1/systemusers(<guid>) indicates the caller is not a systemuser, as it returns “systemuser With Id = <guid> Does Not Exist.”
• The referenced connection ‘shared-commondataser-<guid>’ is not visible in the maker portal under Dataverse > Connections.

Reference Material

• MSFT: Using a Connection References in a Solution
• MSFT Power Automate Community:
• The caller with object id does not have permission for connection under Api ‘shared_sql’ and failed during http send request errors
• MSFT Power Automate Community:
  Caller does not have permission for connection under Api ‘shared_logicflows’
• COE Starter Kit: [CoE Starter Kit – Documentation] The caller with object id ‘GUID’ does not have permission for connection – add documentation on how to fix this co-auth issue #947
• Helpful Bit: Upgrade Flows to Use Connection References

The Helpful Bit

In order to understand why this error occurs, consider the solution import process, as it relates to connection references.  Upon import, if the solution contains connection references, the system checks each one to determine if it is already set.  If not, as when the connection reference is first imported, the user will be required to select an existing connection, or create a new one. If however, one is already set, the system does not prompt the user to select a connection, even if the connection is owned by another user, and not accessible to the user importing the solution. As a result, after import, the attempt to activate the flow fails, generating the above error.

This generally occurs if solutions have been imported using different accounts. This can easily happen when multiple developers create flows using their own credentials, and import them to the target environment, inconsistently using their own account, or service account(s), or later change connection references using a different account. It can be fixed by one of several ways, depending on how you wish to organize your connections, and under what credentials the flows should be running.

1. Update the original solution to use a new connection reference that does not yet exist in the target environment and reimport.
2. Update the connection reference to use a new connection in the target environment. Note, this will affect all of the exiting flows that use the old connection. If those flows do not have access to the new connection, they will error, so you will need to ensure these other account(s) have access to the new connection. In fact, another user making this very change may be the cause your pre-existing flow(s) quit working.
3. Login to the account that owns the connection used by the reference and activate the flow using that account. Flow ownership should probably be set to match the connection owner.

To ensure this doesn’t happen again, take inventory and consider consolidating your connection references. Verify that that the dev accounts all have access to shared connection references and know to use them when authoring flows.  If you have been developing for some time, you may find the list of connection references to consolidate may be quite long, often with numerous connections for the same service, using the same connection, with the same display name. This happens as developers create new references with each flow, rather than using an existing one, often because the default name isn’t visible, clear or confidence inspiring, or the connection it references is not shared with them.

Generally, the references for a given service can be consolidated to a few service accounts (sometimes even just one). Decide what these account(s) should be, give their connection references meaningful names, and update the dependent flows from the other references to use them, instead. Then, delete the unused references. Ensure your developers all have access to the appropriate service accounts / connections and use the correct ones moving forward.

Conclusion

This error is caused due to the account used during import not having access to the connections referenced. Update the connection references and you’ll be good to go.