In our last blog you learned how to migrate to Power Automate in the wake of SharePoint 2010 Workflows going away. Now, we will discuss governance and monitoring for Power Automate platforms.
In order to create an architect and governance plan for Power Automate, it is better to create multiple environments. An environment is used to store, manage, and share your workflow across multiple environments. For example, you can have one environment to build workflows, another environment for testing, and likewise for production. All admin actions in environments are performed by an environment admin. The environments are bound by their geographical locations. When an app is created in an environment, it is only routed to data centers located in a specified location. Once environments are defined, you can move on to the next step to secure the environments.
Azure Active directory is used for authentication and getting access to Power Automate studio. The Power Automate studio requires a license to use that product. You can create a security group, once the user has valid authentication. You can add users as members to that security group. Depending upon the level of permissions, these groups are assigned to each environment. For instance, if a user has the right to create a Power Automate in a default environment, then the user can only read and use permission in the production environment.
Data Loss Prevention Policy
The data loss prevention (DLP) policy feature in Power platform is designed to impose which of the connectors can access important business data. These connectors are divided into two categories: Business Data Only (BDO) or No Business Data (NBD). Admins can define and design data loss policies in such a way that they can apply the policy to all environments within one tenant or specific environment. In order to build a DLP policy, create a policy that can be applied to all environments or one environment by selecting BDO or NBD type connectors as your business need.
Now, I’m going to list out the features that are currently available for you to utilize in order to create a comprehensive plan for workflow monitoring.
Admin center is used to manage environments. A single default environment is created for each tenant automatically by Power Apps. This single default environment is shared by all users in a tenant. Now, you can create environments in Power Platform admin center using dynamics 365 admin center. The admin center can also limit environment creation and, you can see all environments with or without database.
The admin analytics for Microsoft Power Automate provide reports about usage, errors, shared flows, connectors, and types of flow created. The environment admin, Power Platform Service admin, Dynamics 365 Service admin, and Microsoft 365 Global admin with a license can view these reports.
To track the history of a workflow, Power Automate run history is only stored for 28 days. One way to keep the history is to write changes and history in a separate SharePoint list for future reference if you want.
The run time limitation for Power Automate is 30 days. If you want to continue workflow even after 30 days, you must create a recurrence type workflow.
The version control feature is not available in Power Automate. The idea is in review from Microsoft and they may add the functionality in the future as its highly requested feature. One way of keeping the version history of a workflow is to export the workflow as a package solution. You can also import packages into different environments. You can automate the versioning process by generating new workflow anytime the workflow changes and move it to backup environment.
Power Automate Admin Connector
This feature is in preview. Power Automate Admin Connector allows an admin to schedule or instantly run a report of activities within a specific environment or tenant. There are reported items that include listing environments, connections, flows and list of owners and users. Some connector actions include creating and deleting, turning flows on\off , and modifying permissions and ownership on a flow.
PowerShell Cmdlet for Power Automate Creator and Administrators
The admin can get access to Power Apps and Power Automate by using PowerApps PowerShell script function (cmdlets).
Install-Module -Name Microsoft.PowerApps.Administration.PowerShell
Install-Module -Name Microsoft.PowerApps.PowerShell -AllowClobber
It bypasses the route to admin portal in a web browser. You can write complex scripts to customize your workflow by combing PowerShell functions and cmdlets.
The Office 365 license allows some limited Power Automate features. Microsoft updated the license policy in October 2019 and now you can have only per user (allows the users to run unlimited applications) or per flow plan (allows organizations to implement flow without having a license). Per user plan bifurcates into Power apps per user plan and power automate per user plan with RPA and AI functionality.
We hope that you now have a greater understanding about migrating from SharePoint 2010 Workflows to Power Automate, and how to govern and monitor this platform. If you have any questions or would like to discuss this topic further, we welcome you to contact us today!