Part 2: Azure Pipelines for Power Automate Flows: Service Principals
Azure Pipelines for Power Automate Flows Part 2: Service Principals
A blog post by Robert Pröll
Posted: 01.2021 | Category: ALM | Author: Robert Pröll Tags: DEPLOYMENTS CI/CD DEVOPS ALM POWER AUTOMATE FLOWS DYNAMICS 365
Robert Pröll | .NET Software Architect
Intro
This part 2 of a previous blog post, see: Azure Pipelines for Power Automate Flows
We always recommend application users (See: Create an D365 Application User via Script) for deployment tasks. There are a few things need to be done to make this work for Flows.
The provided code is just a basic proof of concept (POC). In a real-world scenario, it is more complicated as many error messages and side effects are misleading, and these problems need to be detected quickly during a failed production deployment.
We basically use the same approach in our products (KDDM Release Q2/2020) and can confirm that it is stable. However, for enterprise environments, a number of additional tasks be carried out. If you have direct access to all systems (incl. AAD), our POC should be a good start.
General Recommendations / Best Practice:
Each action is executed in a specific user context. It is important to understand the difference between the owner and the “execution user”. The example shows a connection which is executed as “admin” – a technical user.
It's also possible to use application user instead of technical service accounts but this a little bit more tricky.
This is what i usually recommend to customers:
Personal Account (e.g. alans@CRM572864.OnMicrosoft.com):
Not recommended, there are many reasons:
- Many records are “modified by” a real person
- External consultants may leave the project
Technical Service Account (e.g. admin@CRM572864.onmicrosoft.com):
- Required as “service owner”
- Used to active flows
- Recommended context user for connections
Application user (e.g. f1bdf92d-c856-4a1a-9645-3c020142163f):
- Owner of the flow
- Recommended for deployments
Troubleshooting
Avoid using personal accounts to create connections
ConnectionAuthorizationFailed:
The caller with object id 'f04bf86a-aacd-4400-9ee9-b75e0d983ae2' does not have the minimum required permission to perform the requested operation on connection '9759435c8ff24e6daf57eb890ad9db61' under API 'shared_commondataserviceforapps'."}} and request url https://api.powerapps.com/providers/Microsoft.PowerApps/scopes/service/apis/..
Cause: The used connection uses a different account:
If try to update the connection-ref. with a technical account to a connection owned by another account, you'll get the mentioned error.
Solution: Login as technical user and create the necessary connections.
Use impersonation to active (set state) of imported flows.
BapListServicePlansFailed / MissingUserDetails
The user details for tenant id 'cab555e0-ef1a-4df6-908f-07d0bb911d09' and principal id 'ac7d11e5-b249-40d0-a7db-0bd65213da9e' does not exist.
Cause: You cannot active a flow as service principal (application user).
Solution: Impersonation: Just set the CallerId to a technical service account.
More Information
Are you looking for a way to improve productivity with business process automation via Power Automate (previously known as Microsoft Flow), then check out below:
Webinar:
Azure Pipelines for Power Automate Flows
Feb 11, 2021, 3:00 PM - 4:00 PM (GMT+1)
https://www.linkedin.com/events/webinar1-azurepipelinesforpower6758313202553012224/
Follow us:
https://www.linkedin.com/company/kuppsoft
KDTooling Deplyoment Manager
We provide a easy to use solution to automatically setup all flows during solution deployment.
More details: KDTooling Deployment Manager
Robert Pröll
.NET Software Architect
Key areas of interest: ALM, .NET C#, PowerShell, Azure, Dynamics 365 Tooling
Robert started in the area of ASP.NET projects and has now more than 10 years of experience in the international Dynamics Enterprise business.
He works mainly as an principal software architect at Kupp and as a external consultant for Microsoft.