DEV Community

Cover image for Power Platform - Moving All Flows to Dataverse
david wyatt
david wyatt Subscriber

Posted on

Power Platform - Moving All Flows to Dataverse

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

environment settings

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.

  1. The Process
  2. The API and how to use it in a Flow
  3. 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).

sdd

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:

full sdd

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

{{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)

common data service

Body

{"flowsToMigrate":
    [
        {{resourceID}}
    ]
}
Enter fullscreen mode Exit fullscreen mode

{{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)

entra 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.
trigger inputs

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

system user id

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

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.

change owner

[
  {
    "properties/principal/id": {{service account objectId}},
    "properties/principal/type": "User"
  }
]
Enter fullscreen mode Exit fullscreen mode

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:

connection inputs

The body has a one dimensional area of the resourceid/name of the flow, so we use a select to convert it.

select to 1 dimen array

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.

getting user and flow

azureactivedirectoryobjectid eq '@{items('Apply_to_each_Flow_remove')?['properties']?['creator']?['userId']}'
Enter fullscreen mode Exit fullscreen mode
resourceid eq '@{items('Apply_to_each_Flow_remove')?['name']}'
Enter fullscreen mode Exit fullscreen mode

We then modifed the flow record in the process/workflows table by changing the lookup column Owner(Owner).

set owner

systemuser(@{outputs('List_rows_from_selected_environment_user')?['body/value'][0]?['@odata.id'])}
Enter fullscreen mode Exit fullscreen mode

And then finally remove the service account as an owner:

remove service account


And thats it, the first x flows are now solution aware.

full flow

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)

Collapse
 
balagmadhu profile image
Bala Madhusoodhanan

this is a cool automation to move the automation :-D...