Deploying Shared Power Automate Desktop Flows

I have previously discussed how we can use shared Desktop flows to centralize logic and make it reusable for others in our organization. Please see the following YouTube video for more details: Calling Shared Desktop Flows from Power Automate Desktop.

As part of that discussion, we needed to ensure that any user that wants to call our shared Desktop flow has the right permissions. The permissions available include User or Co-Owner. When someone has User permissions they can call your desktop flow, but they cannot make any modifications. Whereas, a Co-Owner would have edit permissions.

In a development environment, this sharing becomes straightforward. The owner of the Shared desktop flow would choose the appropriate permissions with either users or Microsoft Dataverse Teams (which can be mapped to an Azure AD group).

The next question is, how do I deal with this in production? For others to call your desktop flow in another environment, it needs to be there prior to their use. So, in this case, the owner of the Shared CoE Desktop Flow needs to deploy it in production first. From there they would go ahead and share it with the appropriate users or Dataverse Teams.

Now, what happens when we have subsequent deployments of the shared desktop flow? This is where a decision is required by the desktop flow owner.

Assuming the inputs and outputs of the shared desktop flow have not changed, the way in which the desktop flow was deployed has an impact on the permissions.
After we have made our changes in our development environment, we can export it as a managed package. We can subsequently change our environment and import this managed package into our production environment.

During the Import a solution step in our deployment process we have an important decision to make. If you click into the Advanced settings area, you will see we have a couple options that impact the behavior of our solution package.

The default value is Upgrade which is called out as the recommended approach. It is considered the recommended approach because it will ensure you have no ‘left-over’ components that may have been removed from your solution in the dev environment. However, the problem with this mode is that it will remove all of your existing permissions. So if you previously shared this package with people and deploy using this mode they will no longer have access to your desktop flows. This can lead to downtime and runtime errors for those dependent desktop flows, until you fix the permissions.

Alternatively, you can select Update. The reason why this approach is considered not recommended is that it will only overwrite components that are both in your solution package and those that were previously deployed. So if you deleted a component in dev and then you deploy your new solution, that same component will remain in production. In the context of building Power Apps and tables, this probably makes sense. But in the context of RPA, breaking existing desktop flows is too much of a risk. As a result, I would recommend using Update in the context of Shared RPA desktop flows.

What about Automated Deployments?

If you are familiar with the Power Platform Build Tools, you will know that you can deploy solution packages in an automated manner. What is interesting about these tools is that by default they will apply Updates to solution packages. So if you were overly concerned about the “not recommended” label, that should ease any concerns.

Conclusion

In this post, we discussed how to manage permissions for shared desktop flows across deployments. What is very important here is to understand the differences between Upgrade vs Update. Both of them have their merits, so it is important to understand the behavior and then make the appropriate decision based upon your requirements.

To see a video version of this content, please check out the following YouTube video: Deploying Power Automate Shared Desktop Flows, Managing Permissions.