One of the best updates for Power Automate was the roll out of Solutions, solutions are packages that hold flows (as well as apps, agents, pages, tables, and much much more), keeping them organised, related, and alm ready. They have beneifts for not just developers, but platform admins too:
Developer
- Connection References
- Environment Variables
- One Export package for deployments
Admin
- Visibility without needing to share edit access
- Group togther for easier monitoring
- Premium App license can cover linked flows
- Run logs in Dataverse
Just to name a few
With solutions being the way top go Microsoft enabled 2 key functions:
- Move to Soluton (for legacy flows)
- Default New Flows as Solution Aware
So now there will be no new legacy flows and developers can migrate all their legacy flows, and this is great with one issue, the Default. Any established Default environments will have hundreds if not thousands of legacy flows, that will never get moved over.
Fortunantely looking at the developer migration process I identifed an API that can be used to make this whole process automated.
- The Process
- The API and how to use it in a Flow
- The Flow
1. The Process
So the plan is simple, we are going to grab all of the flows in an environment (most likely the Default environment) and move them to a solution (for simplicity the Common Data Service Solution).
Sadly it isnt quite that easy, as we have 2 hurdles:
Cant Move Solution aware flows - so we need to filter them out
SYSTEM flows will be in the list - so we need to filter them out
The Mover of the Flow becomes the owner - so we need to change owner
So now we need a few extra steps:
Call out here, if the connections are broken then you can't switch the flow owner back, so you might want to add a step to check broken connections/share with the owner & notify them to fix connections and remove other owner
2. The API and how to use it in a Flow
The API we are using is a flow api, its structure is pretty simple
https://api.flow.microsoft.com/providers/Microsoft.Flow/environments/{{environmentID}}/solutions/{{solutionID}}/migrateFlows?api-version=2018-10-01
{{environmentID}}
- environment id from url
{{solutionID}}
- solution id moving to (you can use the Common Data Service Solution if you don't want to set new ones up)
Body
{"flowsToMigrate":
[
{{resourceID}}
]
}
{{resourceID}}
- flow id from the url
This is an array so multiple flows can be added in one batch
To use the API there are 2 options:
- Create SPN in Azure with Flow permissions and then create Custom Connector
- Use the HTTP with Microsoft Entra ID (preauthorized) (more information here The Super Connector)
Reemeber to change out the solution id to the id of the solution you want to move it to
Trigger Inputs
Ive add a couple of inputs to make the process more robust.
Service Account - temp owner, for security use a Service Account so no edits of flows can happen, this is its Azure/Entra Directory ObjectId
Chunk - How many you want to do in one go, to be on safe side a phased approach is better then doing all in one go (do-check-repeat)
SYSTEMID - Id of the SYSTEM user in the environments systemuser table
The SYSYETM ID can be found in the User/systemuser table
Filter Flows
The filter removes any flows that have a workflowEntityId, as this is only allocated when it is in the Dataverse workflows table. We also check the userId from the List Flows as Admin (V2) action (note the userId for flows not in a solution but owned by a normal account will be the Azure/Entra Directory ObjectId)
Filter to remove solution aware flows and SYSTEM owned flows.
@and(
not(contains(string(item()), 'workflowEntityId'))
,
not(equals(item()?['creator/userId'],triggerBody()['text_1']))
)
Change Owner to Service Account
We use the Modify Flow Owners as Admin Change Owner action to add the Service Account as a co-owner.
[
{
"properties/principal/id": {{service account objectId}},
"properties/principal/type": "User"
}
]
Move the Flows
To move the flows we are going to use HTTP with Microsoft Entra ID (preauthorized) as shown above. The connection should look like below:
The body has a one dimensional area of the resourceid/name of the flow, so we use a select to convert it.
Change Owner Back
First we need to find the origional owner to change the ownership back. We loop over our filtered flows again and first find the users systemuserid from the user/systemuser table and the workflowid from the process/workflow table.
azureactivedirectoryobjectid eq '@{items('Apply_to_each_Flow_remove')?['properties']?['creator']?['userId']}'
resourceid eq '@{items('Apply_to_each_Flow_remove')?['name']}'
We then modifed the flow record in the process/workflows table by changing the lookup column Owner(Owner).
systemuser(@{outputs('List_rows_from_selected_environment_user')?['body/value'][0]?['@odata.id'])}
And then finally remove the service account as an owner:
And thats it, the first x flows are now solution aware.
As always a copy of the solution can be found here.
If you would like to get notified every new blog (I also do a few in the Power Platform Community), subscribe below
Top comments (1)
this is a cool automation to move the automation :-D...