Microsoft Power Automate provides 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 specific connections created and shared across the organization. Power Automate Flows offer a wide array of connectors and the ability to identify which of these are used and the connections created is essential to applying security policies to the Power Platform.

This article begins by discussing the concept of solution aware flows. After that, we will briefly touch on the Power Automate admin connectors available for both Power Automate Flows. Tool sets for PowerShell will be explored that allow administrators tight control and visibility across a tenant. Finally the audited events for Power Automate will be detailed which will lead us into the Office 365 Security and Compliance topic.

Differences between My Flows and Solution Flows


Before getting into the different flow events that can be managed and reported on, we need to first address the differences between My Flows and Flows that are contained within a solution. My Flows are created in the portal and reside within the environment the maker created them in. Flows within solutions, have similar characteristics as My Flows but reside within a Common Data Service solution. These are called "solution aware flows". The distinction may seem small at first but actually has a big impact into what we can do as both makers and admins.

My Flows:

Author's Note: Click each image to expand and clarify

Solution Aware Flows:

Reviewing the article Power Automate Analytics, we begin to see where differences in reporting and even the tools we can use differ between the two. In that article, the analytics reported from either a My Flow or a solution aware flow show much different level or insight. Each flow within a solution can be viewed across an environment while My Flows are shown individually.

For tooling, My Flows do not have a concept of using the Common Data Service's current environment as shown in Aaron Richards' article "Using the Common Data Service (Current Environment) Power Automate Connector". As the article showcases, utilizing the Common Data Service current environment connector allows for actions such as bound and unbound actions, utilizing FetchXml and other Dynamics 365 or Model Driven App concepts.

Another very important piece to point out is Application Lifecycle Management with Flows. As an enterprise utilizing flows in a production ready environment, administrators will want automation tools to migrate changes from developers. Solution aware flows, as part of a Common Data Service solution, can be neatly packaged and moved across sandbox and test environments towards production. They also can leverage existing tools such as Solution Packager to unpack and store within source control.

Finally, solution aware flows allow administrators the ability to use additional API and PowerShell commands to report and manage flow and individual flow runs. This article continues down this path as we explore the Power Apps Connectors and Power Apps PowerShell commands.

Quick Note on Connectors and Connections


The connection and connector actions for Power Automate include the Power Automate Management and Power Automate for Flow connectors. Connectors represent what can be connected to with a Power Automate Flow or Power Apps Canvas App. For this article just be aware that administrators can list all available connectors and connections or get a specific connector and connection.

Data Loss Prevention Policies need to also be briefly mentioned here as well as they are useful for restricting access to connectors in your enterprise. As detailed in "Introducing HTTP and Custom Connector Support for Data Loss Prevention Policies" by Jonathon Levesque, these policies can be used for HTTP and Custom Connectors as well as other First and Third party integrations. A deep dive into DLP Policies will be included in the Connections and Connector article.

Some of the PowerShell tasks addressed below are part of the connectors while others are not currently available. Consider the use of both the PowerShell module for Power Apps Administration tasks as well as the Power Automate Management and Admin Connectors as part of your governance strategy. A good article to review for this is "Power platform Security & Governance: Deploying a Defense in Depth Strategy" by Kent Weare.

Power Apps Administration PowerShell Tasks


The PowerShell module for Power Apps Administration tasks is an extremely useful way to view and take action on environments, apps, flows, connectors and permissions. The PowerShell Support for Power Apps page contains a list of common operations an administrator would find useful for governing an organization's use of the Power Platform and its environments. Some commands I'd like to call out are:

Command Description
Get-AdminDlpPolicy Displays all of the Data Loss Prevention Policies
Remove-AllowedConsentPlans Can be used to remove the ability for uses to create trial licenses. NOTE: It is important to note that when using Remove-AllowedConsentPlans all existing plans of the specified type will be removed from all users in the tenant and will not be recoverable.
Set-AdminPowerAppEnvironmentConnectionRoleAssignment Update connection permissions
Set-AdminFlowOwnerRole Changes the owner of a Power Automate Flow. Again, useful for reassignment.
Get-AdminFlowUserDetails Read a user's Power Automate settings, which are not visible to user, but that support flow execution
Get-AdminPowerAppConnector Returns a list of all custom connector details in the tenant.

The "Get" cmdlets can all be used for reporting and logging of the current state of an environment. The below command from the examples on the Power Apps PowerShell page shows how to use the Export-Csv cmdlet with the -Path argument to write to a text file. In this example, we will get all flows in an environment.

Get-AdminFlow | Export-Csv -Path '.\FlowExport.csv'

With the Get-AdminFlow command below, we are filtering for flows with the word "Approval" in the title.

Get-AdminFlow -EnvironmentName '{Environment Name}' *Approval*

To view a specific user's flows across all environments, use the Get-FlowOwnerRole command:

Get-FlowOwnerRole -PrincipalObjectId '{userId}'

Consider the use of these commands with techniques discussed in Part 2 of Power Automate - Auditing and Activity Logs for additional logging capabilities.

For additional Power Automate samples, please visit the Monitoring the Power Platform GitHub repository.

Activity Events for Power Automate


What events are audited?


The events audited by the Office 365 Security and Compliance Center allow for administrators to search across multiple services offered including Power Automate. These logs are collected at the SDK layer, meaning one action can actually trigger multiple event logs in the log store. Events collected include flow lifecycle actions such as when an flow is created, edited or deleted. User actions include modifying permissions or working with paid trials.

Common Audit Properties


Each audit record includes common properties that can be used to help search or even correlate events together. Fields such as precise time stamps, the specific Power Automate Flow, the operation performed and Identity of the record. The Identity value is key as it can help us better understand a chain of events.

Field name Description
Date Date and time of when the log was generated in UTC
App Name Unique Identifier of the Flow
Id Unique GUID for every row logged
Result Status Status of the row logged. Success in most cases.
Organization Id Unique identifier of the organization from which the log was generated.
CreationTime Date and time of when the log was generated in UTC
Operation Name of operation
UserKey Unique Identifier of the User in Azure AD
UserType The audit type (Admin, Regular, System)
Additional Info Additional information if any (e.g. the environment name)


List of Events


The article, Microsoft Flow audit events now available in Office 365 Security & Compliance Center, by Kent Weare explains the various activities that are audited for Power Automate Flows. It also goes into the Office 365 Security and Compliance Center discussed in Part 2.

Created flow Description
Created flow Creating a flow
Edited flow Updating a flow
Deleted flow Removing a flow
Edited permissions Adding a Owner or Run-Only User(s)
Deleted permissions Removing an Owner or Run-Only User(s)
Started a paid trial Power Automate user started a paid trial
Renewed a paid trial Power Automate renewed a paid trial


Life Cycle Events


Life cycle events include when a maker creates, edits and deletes a Power Automate Flow. These events include the exact time that a user created or modified a flow.

Edited / Deleted Flow Permission Event


The Edited Flow Permission event can show administrators which flows are actively shared between users and groups. Flow permissions can be set to Owners or Run-Only Users. The image below shows a sample of setting the run-only permission, highlighting the connections users and the scopes available.

Next Steps


In this article we have covered getting started with the Power Automate Management and Admin Connectors. Each offers unique actions to help administrators report and taken action on environment flow. Continue exploring the capabilities of these connectors and actions through usage within Power Automate Flows or Canvas Apps.

We have also covered the what activities are currently captured for Power Automate. Discussed in Part 2 are techniques to view the audit logs within the Office 365 Security and Compliance Portal as well as automated techniques.

This article is designed to supplement the article on Power Automate Analytics, which provides more of an all up view of Power Automate usage. Combining these two documents, an administrator can now track analytic metrics as well as the events that define those metrics.

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.



Monitoring the Power Platform: Introduction and Index