Personalized Community is here!
Quickly customize your community to find the content you seek.
Have questions on moving to the cloud? Visit the Dynamics 365 Migration Community today! Microsoft’s extensive network of Dynamics AX and Dynamics CRM experts can help.
2021 Release Wave 2Discover the latest updates and new features releasing from October 2021 through March 2022.
2021 release wave 2 plan
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Community | FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
It has been a while now that we have had connection references available within Power Automate. Many are becoming more familiar with using these and as the adoption grows, there are some scenarios that I want to cover with the community. These are primarily focused on scenarios where they are multiple developers/makers working in an environment.
Lets make sure we cover some of the basics first.
Connections - These are user owned and specific. There is no concept of sharing connections, even if you share a flow. There is also no visibility to view or use another user's connections in an environment.
Connection Reference - These are also user owned and user specific. It is the link between a user, an action within a flow and the connection to that specific data source. If a user has the proper security privileges, they can see connection references owned by other users within Solution Explorer. However, if they Edit the connection reference, the connection will show blank, because you cannot see other's connections. This can cause some confusion.
For example, TestUser created a connection reference using their own connection. When I sign in as my personal user, this is what it looks like when I look at TestUser's connection reference:
It looks as though it is not assigned to a connection, when it actually is. If I change this connection as my user, it will update any flow using this connection reference to then use my connection instead. Now, if I look at if from TestUser's account, you will see it is actually using a connection:
We will look at how this works in a scenario with only one developer/maker creating flows who is also doing the import of the solution into the destination environment. This is more common for a smaller deployment.
TestUser creates a new solution with a new flow that uses their Dataverse connection and their connection reference (TestUserDataverse).
TestUser then export this from the Originating environment into the Destination environment. When the do the import, they will be prompted to fill the connection reference with a connection THEY own. If they don’t have one, they will have to create one. This prompt occurs because the connection reference exists in the solution and does not yet exist in the Destination environment.
After this has been imported, the Flow is enabled and using the proper connection and connection reference. All is well.
Now, we will look at what happens when you have multiple devs/makers working on flows
Scenario 2: This scenario is looking at multiple developers/makers creating and modifying flows in an environment where they would continue building on the flow using another user's connection and connection reference.
This scenario looks at multiple users building flows within an existing solution, which already exists in the Destination environment that were originally imported by one user, but the updated solution being imported by another user.
Why does this happen? It is due to the lack of visibility for User AR to see the connection owned by TestUser during the import. This is something the product group is actively working on.
This scenario looks at multiple users building flows within a new solution, which uses connection references that already exist in the Destination environment (from another solution import) that were originally imported by one user, but the new solution, containing new flows, being imported by another user. Another common scenario of this is creating a solution that contains all connection references and importing to all environments as one user and new flows and solutions being imported by other users
This scenario looks at multiple users building flows within a new solution, which uses connection references that already exist in the Destination environment (from another solution import) that were originally imported by one user, but the new solution, containing new flows AND existing connection references, being imported by another user.
The best method to work through these issues, until they are addressed through the product, are as follows:
Note: These same examples are valid for both manual import and automated deployments, as well as with using Service Principals.
Thank you for reading.
Business Applications communities