Flows tied to personal accounts break when people leave, passwords expire, or MFA blocks an overnight run. This lesson teaches you how to create Azure AD service principals and Power Platform application users so your automation runs 24/7 without depending on any individual employee.
Picture this: you've spent weeks building a sophisticated Power Automate solution that syncs customer data from Salesforce into Dataverse every night at 2 AM. It works beautifully in development. You promote it to production, everything looks great — and then your colleague Sarah goes on parental leave. Suddenly, your overnight sync starts failing because the flows were running under Sarah's personal account, and her license has been temporarily reassigned.
This is one of the most common and most painful production failures in the Power Platform world. Flows tied to a human user's identity are fragile by nature: people leave companies, passwords expire, MFA prompts block unattended runs, and accounts get disabled during off-boarding. The professional solution to this problem is building your automations on service principals and application users — non-human identities that exist independently of any individual employee and run 24/7 without interruption.
By the end of this lesson, you'll understand what service principals are, why they matter for enterprise automation, and exactly how to create and configure them so your Power Automate flows can run reliably without depending on a real person being logged in.
What you'll learn:
This lesson assumes you've worked with Power Automate before and understand basic concepts like flows, connections, and environments. You should have at least read-only access to the Azure portal and Power Platform Admin Center — you'll need an administrator to complete some steps if you don't have those permissions yourself. Familiarity with deploying solutions across environments will give you helpful context, since service principals become most critical during environment promotion.
Before we set up anything, let's make sure we deeply understand why this matters. When you create a flow in Power Automate and add a connection to SharePoint or Dataverse, that connection authenticates using OAuth — the same login token associated with your personal Microsoft 365 account. The flow is effectively "running as you."
That works fine when you're the one testing it. But consider what happens in production:
Account dependencies. The flow is licensed through you. If your license changes or is revoked, the flow stops.
MFA interruptions. Modern authentication policies often require periodic re-authentication. Unattended flows cannot complete an interactive MFA prompt at 2 AM, so they fail silently or throw authentication errors.
Shared connection chaos. When you leave a team and someone else needs to take over a flow, they have to re-authenticate every connection manually. In a solution with fifteen flows and eight connections, this is hours of painful work.
Audit confusion. If every API call made by your automation shows up in audit logs as "Sarah Chen," it's impossible to distinguish legitimate human activity from automated operations. Security and compliance teams hate this.
A service principal solves all of these problems by giving your automation its own dedicated, non-human identity in Azure Active Directory (AAD). Think of it like a badge for a robot — just as a security system doesn't hand out human employee badges to the coffee machine, your automation shouldn't use a human identity to do its work.
Key insight
A service principal is not a licensed user. It exists in Azure Active Directory as an application registration, which means it authenticates using a client ID and secret (or certificate) rather than a username and password. It never needs to respond to MFA prompts, and it never goes on vacation.
Every service principal starts as an app registration in Azure Active Directory. This is where you define the identity — give it a name, generate credentials, and specify what API permissions it needs.
Log into the Azure portal at portal.azure.com. Navigate to Azure Active Directory → App registrations → New registration.
Fill in the form as follows:
svc-powerautomate-dataverse-prod is much better than MyApp. The naming convention matters — when you have dozens of service principals in a large organization, you'll thank yourself later.Click Register. Azure will create the app registration and take you to its overview page. Note down two values you'll need later:
Your service principal needs credentials to authenticate. Navigate to Certificates & secrets → Client secrets → New client secret. Give it a description like "Power Automate Production" and set an expiration. Microsoft defaults to 6 months, but many enterprise teams use 24 months for automation credentials with a managed rotation process.
Warning
Copy the secret value immediately after creation. Azure will never show it to you again. Store it in Azure Key Vault rather than a spreadsheet or email — see the guide on integrating Power Automate with Azure Key Vault and Managed Identities for the right way to manage these credentials at scale.
For most Power Automate and Dataverse scenarios, your service principal needs the Dynamics CRM API permission (which is what the Dataverse connector uses internally). Navigate to API permissions → Add a permission → Dynamics CRM → Delegated permissions → user_impersonation.
After adding the permission, click Grant admin consent (you need to be a Global Administrator or have the Application Administrator role for this). Without admin consent, the permission sits there but doesn't actually work.
Note
The "user_impersonation" permission name is a bit misleading — in this context it means "allow this application to call the Dynamics CRM API." It doesn't mean your service principal is impersonating a specific user.
An Azure AD app registration gives you an identity in the Microsoft identity platform, but Power Platform doesn't automatically know about it. You need to create a corresponding application user in each Power Platform environment where your flows will run. This is a Power Platform-specific concept: a special type of user record that links to your Azure AD app registration.
Navigate to the Power Platform Admin Center at admin.powerplatform.microsoft.com. Select the environment where you want to deploy your flows (start with your production environment). Go to Settings → Users + permissions → Application users → New app user.
In the panel that appears:
svc-powerautomate-dataverse-prod). Select it. Power Platform will populate the Application ID field automatically from Azure AD.Click Create. You now have an application user in this environment. Repeat this process for each environment (dev, test, production) where your automation will run.
Tip
Application users don't consume Power Platform user licenses, but flows running as a service principal still need a valid Power Automate license assigned at the tenant level. Typically, your organization will have a process flow license or a per-flow plan that covers automated scenarios. Check with your admin if you're unsure.
This is where most teams make their first significant mistake: they assign the System Administrator role to the application user because it "just works" and they don't want to deal with permission errors. Resist this temptation.
The principle of least privilege states that any identity — human or automated — should have exactly the permissions needed for its job, and nothing more. A service principal that runs your nightly Dataverse sync doesn't need the ability to delete environments or modify security settings. If that credential is ever compromised, you want the blast radius to be as small as possible.
Power Platform uses security roles to control what a user (or application user) can do. To assign a security role to your application user, return to the application user record in the Admin Center and click Edit security roles. You'll see a list of all security roles in the environment.
For most automation scenarios, a custom security role works best. Create one that grants:
To create a custom role, go to Settings → Users + permissions → Security roles → New role. Walk through each table and set permissions at the row level (Organization, Business Unit, or User scope) and column level as appropriate.
Key insight
Scoping matters as much as permission level. If your flow only needs to read contact records that belong to your business unit, grant Business Unit scope on Contact read, not Organization scope. This limits what the service principal can see if someone were to misuse the credential.
Here's where theory meets practical flow configuration. In a solution-aware flow, connections are managed through connection references — named pointers to actual connections that can be swapped per environment. This is the mechanism that allows you to use a service principal connection in production while testing with your personal account in development.
In the Power Automate maker portal (make.powerautomate.com), navigate to your solution. Select Connection References from the left panel. You should see connection references for each connector your flows use.
For each connection reference, you need to create a corresponding connection that authenticates as your service principal. Here's how to do this for the Dataverse connector:
Dataverse - svc-powerautomate-prod.Once the connection is created, go back to your connection reference in the solution and update it to point to this new service principal connection rather than your personal connection.
Warning
If you edit a connection reference directly in a managed solution (one that's been imported, not the original), you may hit permission errors. Always edit connection references in the unmanaged layer. Review securing Power Automate flows in production for the full picture on how connection references interact with DLP policies and solution layers.
Beyond the connection, Power Automate flows have an owner — the account that "runs" the flow in terms of licensing and audit. For unattended production flows, the flow owner should be either:
The connection reference approach in the previous step handles the "run as" part — the actual API calls go out under the service principal's identity. The flow owner is still a licensed human or service account for administrative purposes.
For most enterprise deployments, the recommended pattern is:
automation@contoso.com) that's licensed and doesn't leave when employees doThis two-layer approach means your flows are resilient at both the licensing level (the service account doesn't leave) and the authentication level (the actual API calls use a non-interactive identity).
Before you declare victory, test deliberately. Here's a structured approach:
Test 1: Verify the application user can authenticate. Create a simple test flow with a manual trigger that reads a single record from Dataverse using the service principal connection. Run it and confirm it returns data.
Test 2: Verify permissions are scoped correctly. Try to perform an operation your service principal shouldn't be able to do — write to a table it doesn't have access to. Confirm it fails with a permission error, not succeeds unexpectedly.
Test 3: Verify the flow runs unattended. Schedule a recurrence trigger for 5 minutes in the future. Close your browser. Walk away. Come back and check the run history — did it execute without you being logged in?
Test 4: Check the audit log. Go to Power Platform Admin Center → Environments → Audit log (or the Microsoft Purview compliance portal if your organization uses it). Find the records created or updated by your test flow. Confirm they show the service principal name (your app registration name), not a human user's name.
Tip
When troubleshooting connection errors in service principal flows, the error message "AADSTS700016: Application not found in directory" means your client ID is wrong or the app registration is in a different tenant. "AADSTS7000215: Invalid client secret" means the secret has expired or was copied incorrectly.
In this exercise, you'll set up a service principal from scratch and verify it can perform a simple Dataverse operation.
Scenario: Your team runs a flow that creates a "Daily Report" record in a custom Dataverse table every morning. You need to move this off your personal account and onto a service principal before your upcoming vacation.
Steps:
In the Azure portal, create a new app registration named svc-pa-exercise-[yourname]. Note the Application ID and Tenant ID.
Create a client secret with a 12-month expiration. Copy the value to a temporary secure note (you'll delete it after the exercise).
Navigate to the Power Platform Admin Center. Open your development environment. Create a new application user linked to your app registration.
Create a custom security role called Automation - Daily Report Writer that has Create and Read access on the specific custom table (or use the standard Account table if you don't have a custom one). Assign this role to your application user.
In make.powerautomate.com, create a new Dataverse connection using "Connect with service principal" and your credentials. Name it clearly.
Create a simple instant-trigger flow that creates a test Account record using this service principal connection. Run it manually.
Check Settings → Audit log in Dataverse to find the record creation event. Verify it shows your service principal as the creator, not your personal account.
Cleanup: Delete the test account record, the test flow, and the app registration when done with the exercise.
Mistake 1: Creating one service principal for all environments Many teams create a single app registration and use it across dev, test, and production. This defeats the purpose of environment separation. A compromised dev secret could be used against production. Create separate app registrations (or at minimum separate secrets) per environment.
Mistake 2: Forgetting to grant admin consent
You add the Dynamics CRM API permission, but flows still fail with insufficient_scope errors. The fix: go back to API permissions in your app registration and click Grant admin consent for [your tenant]. This requires a Global Administrator.
Mistake 3: The "System Administrator" shortcut Giving your application user the System Administrator security role works immediately but violates least privilege. Six months later, when a security audit flags it, you'll be retroactively building a custom security role under pressure. Do it right from the start.
Mistake 4: Not planning for secret rotation Client secrets expire. If you don't have a process to rotate them before expiration, your production flows will start failing at 2 AM on a Saturday. Use Azure Key Vault with an expiry alert, and build secret rotation into your operational runbooks.
Mistake 5: Using service principals for user-interactive flows Service principals are for unattended automation. If your flow involves human approval steps or sends emails "from" a person, you still need a human connection for those specific actions. Mixing unattended service principal connections with interactive steps in the same flow is fine — just be intentional about which connector uses which authentication.
Warning
If your organization uses managed environments with strict DLP policies, test your service principal connections against those policies in a lower environment before pushing to production. A connector that works with personal auth may behave differently under service principal auth in terms of DLP rule evaluation.
Once you have service principals configured, a whole set of enterprise patterns become available to you. Your ALM pipeline for solution deployment can be automated end-to-end because the deployment itself runs as a service principal — no human needs to be logged in to promote a solution from test to production at 11 PM.
Flows that call external APIs using custom connectors or HTTP actions can use the service principal's token as a bearer token, giving you a consistent authentication story across both Microsoft and non-Microsoft systems.
And when you're building child flow architectures where a parent flow fans out work across many child flows, all of those child flows can share the same service principal connection reference, making the entire architecture portable and environment-agnostic.
The service principal concept also integrates cleanly with monitoring. When every automated action in your tenant is stamped with a service principal identity rather than random employee names, your monitoring and alerting system can filter and alert on automation-specific events with much higher precision.
You've covered a lot of ground. Here's the core mental model to take away:
A service principal is a non-human identity in Azure Active Directory, created by registering an application. It authenticates with a client ID and secret rather than a username and password, making it immune to MFA prompts and human off-boarding events. An application user is the Power Platform representation of that identity — the bridge that lets Dataverse and Power Automate recognize and authorize the service principal within a specific environment.
The configuration workflow is: Register app in AAD → Generate client secret → Create application user in Power Platform Admin Center → Assign least-privilege security role → Create service principal connection in Power Automate → Update connection references in your solution → Test and verify audit logs.
To build on this foundation:
With service principals properly configured, your Power Automate solutions stop being dependent on any individual human and start behaving like true enterprise infrastructure: reliable, auditable, and professionally managed.