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 7 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.