Summary

Microsoft Power Automate provide users the ability to quickly create and integrate applications within the enterprise. With this ability comes concerns with governance to ensure users are allowed the appropriate permissions as well as identifying and highlighting specific connections created across the organization. Flows offer a wide array of connectors and the ability to identify which of these are used is essential.

This article is designed to examine common operations that administrators would use to govern environment flows and how best to work with both the Power Automate Management and Power Automate Admin Connectors.

The Common Data Service and fundamental concepts, such as packaging and distributing customizations with solutions, are paramount to providing an automated and auditable delivery process. With that in mind, we will also explore how the Management and Admin connectors are impacted by the usage of both My Flows and Solution Aware Flows.

Power Automate Management Connector and Actions

Inside of Power Automate and Canvas Apps resides the Power Automate Management Connector which allow administrators the ability to manage flows.

[Author’s Note: Click on each image for clarity]

With this connector within Power Automate Flow, administrators can schedule or run instantly a report of activities within a specific tenant, environment or even a flow itself. Reported items include listing environments, connections, flows and their owners and users. Actionable items include creating and deleting flows, turning flows on and off and modifying permissions and ownership on a flow.

Permissions

The Power Automate Management connector, dependent on DLP Policy, can be used by makers who may not have the appropriate permissions. If the maker does not have admin access they will get an error. This is important to address before we move further into common operations and scenarios with both connectors.

From the article “Announcing new Admin and Maker Connectors for PowerApps and Flow” by Denise Moran:

“Office 365 Global Administrator or Azure Active Directory Global Administrator permissions if you need to search through another user’s resources. (Note that Environment Admins only have access to those environments and environment resources for which they have permissions, and global admins can see all resources across the tenant.)“

Common Operations and Differences between Solution Aware and My Flows

Some of the actions I find useful regularly within this connector include List My Connections, List Flows as Admins, Get Flow as Admin and List Owners and Run-Only Users of Flows. For this section we will focus on utilizing these actions and how they can be used with both My Flows and Solution Aware Flows.

List Connections

List My Connections will list the connections and provide user context and connection status. If a connection has an error code, it can be found here and reported.

List Flows

List Flows as Admin provides a list of flows within an environment. Each flow returned contains the current state, the flow name and when it was created and last modified. For solution aware flows, we can also find the workflow primary key for use with the Power Automate API.

The Common Data Service API call, utilizing the WorkflowEntityId, shown below can be used to find further information about the flow.

 
https://<org>.crm.dynamics.com/api/data/v9.0/workflows(0f67aeac-b03e-ea11-a812-000d3a54663d)

Its important to point out the difference between List Flows as Admin and List My Flows. Comparing the output of both we can begin to see that List My Flows only contains flows that are not solution aware aka My Flows. 
Solution Aware Flows will have the WorkflowEntityId as shown above as well as another value to help distinguish it from My Flows. As shown below, the sharingType property will be “CommonDataService” for Solution Aware Flows.

Get Flow
 
Get Flow as Admin can help admins determine the different triggers and actions that define a flow. This could be helpful to retain a sort of history of My Flows allowing versioning with source control. Get Flow and Get Flow as Admin seem to both return My Flows or Solution Aware Flows. Remember, solution aware flows are packaged within solutions and can also easily be stored in source control with the Solution Packager tool.

Listing Flow Owners and Run-Only Users
 
Working with Owners and Run-Only Users we see another difference between My Flows and Solution Aware Flows. My Flows will return the current owner and run-only users while Solution Aware Flows will not.

Here is a Solution Aware Flow using the List Flow Owners action.

That said, let’s continue to modifying flow owners to understand how we can leverage additional connectors to help out!
Modifying Flow Owners and Run-Only Users
 
Modifying My Flow Owners allows Flow makers to add (put) or remove (delete) other makers or users to become owners. This works the same with Run-Only users as well.

For Modifying Owners for a Solution Aware Flow, the Modify Flow Owner action not only doesn’t work as expected it will throw an error.

Sharing error:
Sharing through Flow is not currently supported for solution-aware flows. Permissions management should be conducted through the environment-linked XRM instance.

However, referencing back to our knowledge that Solution Aware Flows are CDS (XRM) records, we can leverage the Power Automate (CDS) Web API to help. It just so happens the reference to the Power Automate Web API provides examples to listing users who flows are shared and how to share and unshare a flow.
First, let’s review the Flow as is from the Flow Portal. The image below shows a single owner of the flow with no run-only users.

Moving into the Common Data Service, we can see that by locating the flow within the Common Data Service, the flow is not shared with anyone.

Using the Common Data Service current environment connector, we can call an unbound action (GrantAccess) to modify the PrincipalAccess of the Flow to use a systemuser or team. 

PrincipalAccess Formula:
{
  "Principal": {
    "@{string('@')}odata.type": "Microsoft.Dynamics.CRM.systemuser",
    "systemuserid": "{objectid}"
  },
  "AccessMask": "ReadAccess, WriteAccess"
}

Now, reviewing the Common Data Service record for the workflow we can see the updated principal access. The image below is not an accurate representation to the one above. To find out how permissions and AccessRights work, review this document.

For a complete example of this flow, showcasing how to share access to a solution aware flow, click here.
Looping back on Listing Flow Owners
Now that we have discussed the Common Data Service, let’s circle back to the listing flow owners scenario. Reviewing the Power Automate Web API we can see that to list users we need to use a CDS function called RetrieveSharedPrincipalsAndAccess. Here is the CDS documentation. Unfortunately the Common Data Service (current environment) connector currently doesn’t allow for calling functions. In this case we can leverage an Azure Function custom connector or call the Web API using the HTTP connector.
Using the HTTP connector with the CDS Web API, you’ll have to make a call to get the authorization bearer token which can then be used for subsequent calls to the API. The image below shows this conceptually.

NOTE: This technique is based on the documentation found here in the article “Power Automate Web API“. That said I cannot speak to nor guarantee the supportability of what is shown here.
Turn On and Turn Off
 
The Turn On and Turn off actions, as described, can be used to enable or disable flows. From my testing I was able to successfully turn on and turn off both My Flows and Solution Aware Flows using the two actions.

If desired, a sample showing how to update the flow workflow CDS record to turn on or off can be found here.
Power Automate for Admins Connector and Actions

 
Operational differences between My Flow and Solution Aware Flows
 
Enable and Disable
 
Enabling and Disabling flows using the Power Automate for Admins Connector look to work very similar to the Power Automate for Management actions. However, the Power Automate for Admins Connector actions will not work for Solution Aware Flows as they will for the Power Automate for Management connector. Below are example error messages when attempting to start or stop a Solution Aware Flow.


Error:
“CannotStopUnpublishedSolutionFlow” – “An unpublished solution flow cannot be stopped.”
“CannotStartUnpublishedSolutionFlow” – “An unpublished solution flow cannot be activated. Please authenticate the flow connections and save the flow to enable activation.”
Edit Flow Owner
 
This flow action allows an administrator to assign a edit (CanEdit) or view (CanView) role to a user. Unfortunately this action will not work with Solution Aware Flows and like the Management actions, will require the Common Data Service API.

Error:
“EntityFlowSharingNotSupported” – “Sharing through Flow is not currently supported for solution-aware flows. Permissions management should be conducted through the environment-linked XRM instance.”
Actions Tested
 
Power Automate Management Connector
 

 
Power Automate for Admins Connector
 

 
Common Data Service (current environment) Connector
 

 
HTTP Connector
 




Action
Description




Send HTTP Request
Used for the CDS Web API for calling functions and other unavailable actions




 
Making My Flows Solution Aware

 
As discussed in the article “Monitoring the Power Platform: Connectors, Connections and Data Loss Prevention Policies“, Solution Aware flows can be very useful but come with some current known limitations. Some current limitations include:


Button triggered flows are not available in solutions.


Flows triggered from Microsoft 365 applications such as Excel are not available in solutions.


Flows that connect to SharePoint are not available in solutions.


Importing a solution containing a flow will not automatically create or associate required connections. The flow must be edited to fix the connections.


That said, there are benefits to using Solution Aware Flows such as enhanced capabilities like Child Flows or even additional monitoring with Get-FlowRun (more on that in a future article!). If its needed to move a My Flow to a solution and as long as the known limitations do not apply, there are a couple of options an administrator has.
The first option is to manually add a flow from the Flow Portal. This process is fairly straight forward, simply click Add existing, locate the flow in the Outside of Solutions tab and add. This process will create activity records in the Office 365 Security and Compliance Center which can be used for auditing purposes.

The second option which works well with our goals of automation and continuous governance is to use the PowerApps Administration for PowerShell cmdlets. Included in the Microsoft.PowerApps.PowerShell module is a cmdlet called “Set-FlowAsSolutionAware“. This allows us to programmatically add a flow to a solution by providing the environment, flow name and the solution.
Set-FlowAsSolutionAware -EnvironmentName {environmentName} -FlowName {flowName} -SolutionId {solutionId}

This technique can allow us to automate the migration of My Flows using DevOps platforms such as Azure DevOps or GitHub Actions to building custom webhooks with Azure Function or Azure Automation.

Next Steps

 
In this article we have covered working with the Power Automate Management and Admin Connectors. Each offers unique actions to help administrators report and taken action on environment flow. Based on the type of flow we are working with, each connector action provides us different outcomes. 
The actions tested have been listed out for a reference and sample flows have been provided. Finally, we wrapped with the steps needed to migrate My Flows into solutions. 
If you are interested in learning more about specialized guidance and training for monitoring or other areas of the Power Platform, which includes a monitoring workshop, please contact your Technical Account Manager or Microsoft representative for further details. 
Your feedback is extremely valuable so please leave a comment below and I’ll be happy to help where I can! Also, if you find any inconsistencies, omissions or have suggestions, please go here to submit a new issue.
Index

 
Monitoring the Power Platform: Introduction and Index
Let’s block ads! (Why?)
Dynamics 365 Customer Engagement in the Field

			
Search for: