Integrating Microsoft Purview and Power Automate Best Practices
In the final part of our series (Leveraging Power Automate with Microsoft Purview), we provide some best practices and guidance to pull all of this together. Part 1: Leveraging Power Automate with Microsoft Purview (Part 1) Part 2: Integration of Microsoft Purview and Power Automate (Part 2) Part 3: Integrating Microsoft Purview and Power Automate
In the final part of our series (Leveraging Power Automate with Microsoft Purview), we provide some best practices and guidance to pull all of this together.
Part 1: Leveraging Power Automate with Microsoft Purview (Part 1)
Part 2: Integration of Microsoft Purview and Power Automate (Part 2)
Part 3: Integrating Microsoft Purview and Power Automate: Implementation Best Practices (this post)
The series intended to show how Power Automate can be used along with the Compliance capabilities within Microsoft 365. Now that we’ve seen that, some obvious questions need to be answered around process, permissions, and licensing. Let’s dive in.
Process
Building a solution like this requires coordination between several teams in your organization. Building the solution in Part 2, logic and communication are happening on what to look for and what message to send. This requires planning, awareness, and acceptance within the organization, or it might feel like spam to your users. The compliance and security team must also be aware of the automation, as internal or industry compliance may require a specific notification message, tracking, and additional actions.
At Agile IT, we’re here to help make these things happen for customers, but we’re not an auditing or certification company, so this is just some helpful guidance.
Let’s say you have all of this sorted and ready to move forward to take action.
Permissions
When building the flow, the user building the flow will need the appropriate rights to connect to the services that were shown in Part 2. In a production environment, this requires some coordination with the IT/Security team to request and get approval for the user to gain the required access.
This could be short-term access and later changed at the Connection level to a service account.
Service Accounts
Service Accounts as a concept have been around the IT field for decades. You almost feel like we no longer need them, and I wish they were gone. However, we’re not that lucky in the case of Power Automate and the Part 2 example.
Within the context of Microsoft 365 via Entra ID (aka Azure Active Directory), a Service Account is a user (aka member) created to execute actions for a service that requires user authentication, which may also require licensing. This is also terrible because there is a “user” who has permission to do things, and somewhere, there is a password that can be hacked. We’ll talk about all this another time.
There are three reasons why a Service Account is required, and later, we’ll explain in the recommendations how they can go away (in a way):
- Longevity: The connections require association with a user. If we associate this with a “real” user and not a Service Account, then if that user has a change in role with permission changes or exits the organization, then our flow breaks
- Limiting access: The user that created the flow may not require the permissions in the flow. Thus, the user is over-permissioned
- Licensing: The user that created the flow may not have the ongoing licensing to maintain the volume of flow execution or lose access to run the following in the future.
Licensing
Licensing scenarios for Power Automate are exceptionally flexible, which is another way of saying it can be complicated. We’ll keep it simple for this scenario.
When developing the flow and when the flow is running in production, the user or service account will require the appropriate licensing for Power Automate, which includes rights to the Premium connectors we’re using.
In Part 2, the Power Automate flow (we’ll just reference it as flow from now on), the user connections associated with this flow is both running a flow and interacting with Microsoft Teams. In this case, we need a license for that user that can do both things.
What’s needed here is a “Power Automate Premium” or a “seeded” Plan. A seeded plan consists of a Microsoft license (e.g. Microsoft 365 E3) that includes Power Automate Premium.
There is also a new Power Automate meters option that is a pay per run model that’s another option to look at as well.
Let’s not forget that we’re using the Communication Compliance features which also needs to be licensed and configured in the tenant.
Microsoft Communication Compliance requires licensing as well but is no longer available as a stand-alone license.
It’s available within the following licensing options:
- Microsoft 365 E5
- Microsoft 365 E5 Compliance (requires Microsoft 365 E3)
- Microsoft 365 F5 Compliance (requires Microsoft 365 F3)
- Microsoft 365 F5 Security & Compliance (requires Microsoft 365 F3)
All of the users within the organization should have one of these options applied to them or you might not get all the alerting you’re looking for.
Power Automate to Logic App
Now that you have configured your Flow & assigned the appropriate licensing and permissions required you may wonder how you ensure this will continue to run after your (or the designers) departure. How can I leverage this company wide without needing to assign everyone a license. These are both great questions & that is where leveraging a Azure Logic app may be able to assist.
Since Azure Logic apps are tied to your subscription & are consumption based, you could deploy the same application as a Logic app & not have to purchase and assign the power automate license.
Running as a logic application also will allow you to continue running and make changes to the application even once the designer/developer has departed. You can also run the logic app as a managed identity which allows you to assign the required permissions to the app vs implementing them at the user level.
While Power Automate & Logic apps seem very similar, they also have some differences which are key to know:
Here are a few of those comparisons:
Target Audience:
Power automate – end users, business users
Azure logic apps – IT staff, developers
Targeted Data source:
Power automate – restricted to office 365 data only (emails, teams, sharepoint etc,)
Azure Logic apps – Access to Office 365 data and Azure resource data
Run duration:
Power automate- 30day run time max
Azure Logic Apps – 90day run time max
Licensing model:
Power automate – Per user
Azure Logic Apps – Subscription (can be consumption or standard)
Security:
Power automate – Limited to data verse permissions & power automate roles
Azure Logic apps – Fine Grained access control
Recommendations
If this is your first time using automation via Power Automate and you haven’t done anything with Azure Logic Apps, then I’d stick with Power Automate to get things moving quickly. Pull your IT, security, compliance, and HR team together to discuss what you learned in this post series.
The next step is to follow the instructions in Part 2 to test and show your team how this all comes together in YOUR environment. This will help inspire a vision and build a roadmap for further flows and adoption.
You can then sort out the pricing and if/when you should move all this to Azure Logic Apps.
If you need help guiding this process through in your organization, building new flows, and/or guidance on how else to integrate compliance automation in your organizations, that’s what we’re here for at Agile IT.
