DEV Community

Cover image for Power Automate - How to Change Connection Owners
david wyatt
david wyatt Subscriber

Posted on

8 1 1 1 1

Power Automate - How to Change Connection Owners

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.

  1. 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

  2. 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

  1. Prerequisites
  2. Connections
  3. Change Connection
  4. 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
app reg
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.

spn 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.

share connection

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

connections response

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']))
Enter fullscreen mode Exit fullscreen mode

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], '-'))
Enter fullscreen mode Exit fullscreen mode

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.

update 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']}"
}
Enter fullscreen mode Exit fullscreen mode

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

process

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:

full flow

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 😎

Sentry image

See why 4M developers consider Sentry, “not bad.”

Fixing code doesn’t have to be the worst part of your day. Learn how Sentry can help.

Learn more

Top comments (3)

Collapse
 
brynhh profile image
James Holland-Hart

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.

Collapse
 
wyattdave profile image
david wyatt

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?

Collapse
 
brynhh profile image
James Holland-Hart

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.

Image of Datadog

Get the real story behind DevSecOps

Explore data from thousands of apps to uncover how container image size, deployment frequency, and runtime context affect real-world security. Discover seven key insights that can help you build and ship more secure software.

Read the Report

👋 Kindness is contagious

DEV works best when you're signed in—unlocking a more customized experience with features like dark mode and personalized reading settings!

Okay