Why Run Your Flows Under a Service Account

Business-critical flows should never be executed under a user context.

That might sound blunt, but think about it: if a key process in your organisation relies on someone’s personal account, you’re building fragility into your automation. People leave. Passwords expire. MFA gets enforced. Licenses change. Suddenly, your flow—the one that moves invoices, synchronises data, or triggers customer communications—fails.

By contrast, flows running under a service account (service principal) are stable, scalable, and easier to govern.

Why service principals are essential

• No dependency on individual staffAccounts don’t disappear when people do.

• Consistent reliabilityNo interruptions from password changes or MFA prompts.

• Better handling of request limitsAvoid user-level throttling when workloads scale up.

• Security and governanceFine-grained permissions and managed secrets give admins control.

Step 1: Create the service account in Azure AD

1. Go to Azure Active Directory → App registrations → New registration

2. Name it meaningfully, e.g. Power Automate – Finance Flows

3. Record:

   • Tenant ID

   • Client ID

   • Client Secret (or upload a certificate)

Assign API permissions (Graph, Dataverse, SharePoint, etc.) and grant Admin Consent.

Step 2: Store the secret in Key Vault

Hardcoding client secrets in a flow is risky. Instead:

1. In Azure, create a Key Vault and add your service principal’s secret.

2. In Power Automate, add the Azure Key Vault connector.

3. Use the Get Secret action. This ensures the flow retrieves the secret securely at runtime.

   
   

Step 3: Test the service principal in a flow

Once you have the Tenant ID, Client ID, and the secret from Key Vault, you can test directly inside a flow.

Add an HTTP with Azure AD action. Configure it as:

• Method: GET

• URI: https://graph.microsoft.com/v1.0/users

• Authentication:

  • Type: Active Directory OAuth

  • Tenant: Tenant ID from your app registration

  • Audience: https://graph.microsoft.com

  • Client ID: Client ID from your app registration

  • Secret: Dynamic content → Value from your Key Vault Get Secret action

In the designer, it will look like this:

Action 1: Get Secret (Azure Key Vault)

• Vault Name: MyFlowSecretsVault

• Secret Name: PowerAutomate-ClientSecret

Action 2: HTTP with Azure AD

• Method: GET

• URI: https://graph.microsoft.com/v1.0/users

• Secret: @{outputs('Get_Secret')?['value']} (inserted via dynamic content picker)

When you run the flow, a successful 200 response with a list of users means the service principal is working.

Best practices

• Always use Key Vault for secrets.

• Grant least privilege: only the permissions your flow needs.

• Document ownership: tie each service account to a business owner and environment.

• Monitor tenant-level limits: service principals avoid user quotas, but global limits still apply.

Final thought

Running flows under service accounts isn’t just a “best practice”, it’s the difference between fragile automation and enterprise-grade reliability. If a process is business-critical, it deserves the stability and security of a service principal.