One of the key challenges I have found with the built in Power Platform Pipelines is that it doesn't cover connections. The expectation is that the developer will deploy to production through a spn (as we don't want them to have access to edit production), but the new flows use the developers connections, wait what. The 2 benefits of ALM are:
- Cant access prod
- If they leave still works
Well with this setup the developer still needs access to the prod data source, and if they leave it breaks.
Fortunately there is a way, well actually 2.
Matt Collins-Jones found the best way and documented it brilliantly at https://www.mattcollinsjones.co.uk/single-post/change-connections-during-deployments-power-platform-pipelines, I highly recommend reading it
My way is a lot less graceful, but has the one benefit it can be ran outside of deployments (as isnt part of the import process).
So lets dive into my solution
- Prerequisites
- Connections
- Change Connection
- The Full Flow
1. Prerequisites
Currently in platform you can't share connections with other users, only with Apps (SPN'). This means you have to:
Create SPN with Dynamics/Dataverse Scopes
Good guide here
Register the SPN as app in the environment
So that we can give it a security role with access to Solution, SolutionComponent, and ConnectionReference tables
The flow owner account needs System Admin Role
So that it can use 'Get Connections as Admin' connector
The Dataverse connections should use the SPN
So that when we change connections the modifier of the row has permission to use the connection.
Share Connections with SPN
Not going to lie, this step is a pain, as you need to login as the connection owner and share each connection with the SPN.
FYI these steps are also needed for Matts better approach
2. Connections
So connections are in 2 places, the connections table and connection reference table. But if you have ever looked in the connections table you will see its empty, Microsoft knows how sensitive this data is and has secured it well. Luckily there is a way to get connections, and thats with the Power Apps Admins actions (yep the backend of the Power Platform is interesting, as connections are controlled by the Power App api, even though we probably use the more in Power Automate, I have done a blog about the API's if you are interested here: The 4 API's of the Power Platform).
Good news is our flow owner has System Admin role so can see all connections, though not use them (good thing!).
The action returns all the information we need:
- Owner/Creator
- Connection type
- Connection
- Status
With the connections array we can do 2 key filters, first to get the new connections we want to use (this is by the connection owner)
@or(equals(item()?['properties/createdBy/userPrincipalName'], triggerBody()['text_3']),equals(item()?['properties/createdBy/email'], triggerBody()['text_3']))
And the next filter is to get the right connector type (SharePoint/Dataverse/etc), and thats from the properties/apiId field.
@contains(concat(item()?['properties/apiId'], '-'), concat(split(outputs('Get_a_row_by_ID_from_selected_environment')?['body/connectorid'], 'apis/')[1], '-'))
This might make more sense when you see the whole flow 😎
3. Change Connection
With all the hard work done, updating the connection is really simple. We are going to update the connectionReference with the new connection.
The connectionid is the magical field that we want to update, and its the 'name' field from our connections array.
{
"connectionid": "@{body('Filter_array_to_connection')[0]?['name']}"
}
4. The Full Flow
Now lets put it all together in a flow, in this case its a childflow, we pass in the
- environmentUrl:Dataverse
- environmentId: Get Connections
- SolutionName: To find connection references
- ServiceAccount: The new connections owner
We then get all connections, filter to service account. Find the solutions connection references, loop over and update with the matching connection.
And the final flow should look something like this:
You can download it here
One of the things I love about the Power Platform is that its built on itself. The better you are at using it, the more you understand the platform and the more you can get out of it. Microsoft may not think changing connections is important, so hey let's do it ourselves 😎
I've had a few requests for a mailing list to alert new blogs, if you would like to get notified every new blog (I also do a few in the Power Platform Community), subscribe below
You will be pleased to know I built the mailing system myself in Power Automate, so if it doesn't work you know why 😎
Top comments (3)
Hiya David, have you considered ADO pipelines and the Power Platform Build Tools? We’ve been using interactive service accounts and deployment settings that point connection references to the connections of that service accounts for a couple of years and it works really well. Owners don’t need to change, as the owner is the app registration used by ADO to import. If developers need to see flow runs, they currently can just go in and see it, eventually we’re moving over to a combination of managed environments, CoE and Azure for monitoring.
It's something I looked at, but using ADO adds cross team complexity in some orgs, and I like to keep everything within my team. Though I did wonder, do you still have to manually share the service account connection with the pipeline spn?
What issues are you having cross teams? We work across product, engineering, qa and devops/governance teams and find it fine. We have groups which people are members of and different groups approve different stages (environments), with the person who made and oversaw the change kicking off the build. When we fully adopt git integration, the peer reviews and stuff will become easier as part of a PR, work items will be automatically linked,etc.
For the app registration, yep the connection has to be shared with it in shared + edit mode. But that’s fine, as you cant login as it anyway cause it’s not an interactive user. I can’t see any circumstance where we’d change to PP pipelines now. Be happy to chat about it if you like.