Sharing a Connection Reference

[sperry1625]

We are starting Coauthored Development for our Power Apps. We are running into some issues.  Here is a scenario:

Scenario

Developer 1

1. Creates New Solution for Shared Connection References (IT | Common | Connections)
   1. Common Solution contains Connection References for
      1. SharePoint Online
      2. Office 365 Outlook
      3. Office 365 Users

Developer 2

1. Creates new solution
2. Creates/imports Power App and related Flows

Problem

Developer 2, while creating flows, cannot see the common shared connection references created by Developer 1. Why?

If Developer 1 goes into the flow created by developer 2, they can see the connection References and use them. Save the Flow. Then Developer 2 can edit the flow and the shared connection references are still selected (although developer 2 cannot see the account used by the connection reference).

I can see a possible reason; the underlying Connection in the Shared Connection Reference is not accessible by Developer 2.

Even without using a Shared Connection, if developer 1 creates a Connection Reference local to the solution developer 2 will still have an issue as they will not have access to the underlying connection.

How is coauthoring supposed to work if solution components cannot be shared? How does one connection reference use different underlying connections based on what the developer has access to?

Connections can only be shared with Service Principals, not individuals. How is this supposed to work?

Any thoughts would be appreciated.

Thank you.

Regards,

-S

[darylvogan]

JUST the creation step?

[victorcp]

No, creation and development

[sperry1625]

Even using a service account does not solve the problem.  Even if each developer creates a connection with a common service account, the flow or app references the GUID for the connection which is different for every developer. So back to my original question, how does co-authoring work when all developers need their own connections?

[AlexMCC]

So you all share a password to an account without MFA?

[darylvogan]

That seems to be the only way around the issue. How are others doing it?

[ericsnow]

Hi folks,

Glad this thread exists, our team found the same issue last year when we started doing more co-authoring in our solutions . Over the past couple of months we have confirmed with Microsoft support that this is a known issue with connection reference sharing for new Power Automate flows and it has been sent to the product team (no ETA for improvements). For the time being, our developers have been using a couple of approaches mentioned in this thread, either:

1. Create connection references using a generic user account and add them to any new flow using that account, after which time they are available to other developer accounts editing that particular flow, OR
2. Have the developers use their own connection references when developing new flows and then swap them out to consolidate connection references at the earliest convenience (using whichever account owns the consolidated reference). The latest this "swap" must occur in our team's process is before promotion of the solution to non-DEV environments, but I recommend doing it earlier if possible. 

Both approaches have their own set of drawbacks. The primary drawback of "1" is that it is potentially poor from a security perspective since multiple developers may need to access the generic account. The primary drawback of "2" is that there may be a considerable amount of "clean-up" (swapping out connection references) required if you want to consolidate to the minimum number of connection references. As you would expect, the process becomes more time-consuming as the number of flows and activities increases.

[ksoze92]

Hello good people,

I am glad too to come around through this topic, as I am facing a similar situation where I have been asked to develop some cloud + desktop flows and then share with business people so that they can maintain it.

What I have thought is the following:

• Developer develops under his personal account (e.g. andoni@contoso.com), using the connection references (such as outlook) under his account.
• After the developer finishes the development of the flows (cloud flows + desktop flows for example), he shares the flows with a service account (e.g. pa_techuser@contoso.com). Then this service account would use his connection references for outlook and so on.
• Business uses this pa_techuser@contoso.com account to trigger the flows

I suspect that this is not the best option nor I have the full comprehensive picture of how this work, but I just wanted to know your thoughts on this.

Thanks a lot!

Andoni

[prabut]

1. If you make Developer 2 as Co-author in a flow, then Developer 2 will be able to use the embedded connections used in the flow. Everyone listed as an owner will have access to all these connections and will only be able to use them in this flow.
2. Also Connection References can be shared with Developer 2 from Solution -> 'Switch to Classic' mode 

[ksoze92]

1. I've made a cloud flow that uses outlook connection (with developer1@contoso.com account) and I have shared this cloud flow with developer 2 (pa_techuser@contoso.com), making developer 2 as co-owner. When developer 2 runs the flow the outlook connection is developer's 2 (i.e. email is sent from pa_techuser@contoso.com, not from developer1@contoso.com). As far as I've experienced, I cannot change this (whenever I try the "switch account" option in the outlook connector and try to auth with another account this does not work, it keeps on using the same account).
2. What do you mean? From the Connections' tab all I can do is share the connection with a service principal (not with a user)

[AsaurdiffADTill]

This is a bit different then the posted question. Your issue is due to the trigger type. Some triggers infer the user who triggers the flow while others may be able to use the "owner" of the flow. 

So if you had a trigger that used owner, like the post is referring too, then it would assume the user who set up to run the action (i.e your outlook email). If you have a trigger that passes or infers the user who triggered the flow it would insert their email there instead and ignore the action (connected to a connection reference) owner of it. 

Hope this clears up your question at least 🙂