If you’ve spent any time building Power Automate flows in a Microsoft 365 environment, you’ve probably learned to reach for service principals as the default identity for unattended automation. They don’t expire like passwords, they’re not tied to a human user who might leave the firm, and they fit cleanly into a zero-trust security model. For Microsoft-native services – SharePoint, Teams, Exchange via Graph API, Azure resources… they work exactly as advertised.
Then you connect a third-party service and everything stops working.
No helpful error message explaining the architectural mismatch. Just an authentication failure, a connector that won’t authorize, or a flow that runs fine in testing under your own credentials and silently breaks the moment you try to run it unattended under a service principal. If you haven’t hit this yet, you will. And when you do, the problem isn’t your configuration… it’s the fundamental way most third-party Power Automate connectors handle authentication.
This article explains why it happens, what your options are when it does, and how to make the right call for your environment – particularly in a law firm context where unattended flows touch sensitive matter data and auditability isn’t optional.
Why Service Principals Exist and Where They Excel
A service principal is an identity in Entra ID that represents an application or automated process rather than a human user. Where a user account authenticates with a username and password and carries with it all the lifecycle complexity that implies, a service principal authenticates using a client secret or certificate and operates with only the permissions it has been explicitly granted.
For unattended automation, this model is nearly ideal. Service principals don’t have passwords that expire and lock out a critical flow at 2am. They don’t get disabled when someone leaves the firm. They’re not subject to MFA prompts that block a non-interactive process. And because their permissions are granted explicitly through app registrations and API permission scopes, they’re auditable; you can see exactly what a service principal can access and why.
In a Microsoft 365 environment, service principals shine. Power Automate flows calling SharePoint via Graph API, reading Exchange mailboxes, writing to Azure Storage, or interacting with Dataverse all support app-only authentication. You register an app in Entra ID, grant it the appropriate Microsoft Graph or resource-specific permissions, and your flow runs cleanly without any human credential in the chain. This is the architecture Microsoft recommends for enterprise automation, and in the Microsoft ecosystem it delivers on that promise.
The assumption that follows – reasonably, but incorrectly – is that this model extends to everything you connect to Power Automate. It doesn’t. And the reason why gets to the heart of how third-party connectors are built.
The Third-Party Connector Problem
Power Automate connectors are not all built the same way. Microsoft-native connectors are built with app-only authentication in mind – they’re designed to accept a service principal’s token and act on its behalf without a human user in the loop. Most third-party connectors are not.
The reason is architectural. The majority of third-party Power Automate connectors are built on top of OAuth 2.0 delegated authorization flows. In a delegated flow, the application acts on behalf of a signed-in user – the connector authenticates as a specific human identity, inherits that user’s permissions, and performs actions as that person. The entire model assumes there is a user behind the connection. When you try to substitute a service principal – which has no user context, no delegated permissions, and no interactive sign-in – the connector has no framework to handle it. Authentication fails not because something is misconfigured, but because the connector was never designed to support that identity type.
This is not a gap that Microsoft can patch on behalf of third-party connector publishers. Each connector’s authentication model is determined by the publisher who built it and the API it wraps. If the underlying API only supports delegated OAuth flows, the connector will only support delegated OAuth flows. A service principal simply has no place in that handshake.
The practical consequence in Power Automate is significant. A flow that mixes Microsoft-native actions and third-party connector actions cannot use a single unified identity. The Microsoft actions can run under a service principal. The third-party actions cannot. Every third-party connector in the flow requires a connection – and that connection requires a human identity behind it, whether you want one there or not.
In a law firm context, this creates real operational and governance problems. Flows that touch matter data, trigger document actions, initiate signature requests, or interact with practice management systems are often built on exactly the connectors most likely to have this limitation. The workaround you choose has direct implications for security, auditability, and what happens when that human identity is no longer available.
The Workarounds and When to Use Each
There is no single fix for this problem. The right approach depends on the connector, the underlying API, and what your firm’s security and governance posture will tolerate. Here are the patterns that come up most often in practice.
Service Account with Delegated Credentials
The most common workaround is the simplest: create a dedicated service account – a licensed Microsoft 365 user account purpose-built for automation – and use its credentials to authorize the third-party connector connection. The flow runs under this account’s delegated identity, the connector sees a human user, and authentication succeeds.
This works reliably and is broadly compatible with virtually every third-party connector. It is also the approach that carries the most operational risk if it isn’t governed carefully.
The service account needs to be licensed appropriately for both Power Automate and any third-party service the connector touches. It needs MFA configured in a way that doesn’t block non-interactive flows – typically via a Conditional Access policy that excludes it from interactive MFA requirements, which itself requires careful scoping to avoid creating a broad security exception. Its credentials need to be stored securely, rotated on a defined schedule, and owned by a named team rather than an individual. And critically, the account needs to be monitored – if it gets disabled, has its password reset, or triggers a risk event in Entra ID, every flow depending on it will break simultaneously.
Use this approach when the third-party service has no API key or alternative authentication option, when the connector is a standard published connector with no customization path, and when you can put the governance controls in place to manage it properly.
Custom Connector with API Key or Client Credentials
Many third-party services that publish a Power Automate connector also expose a REST API that supports API key authentication or OAuth 2.0 client credentials – the app-only flow that service principals are built for. If that’s the case, you can bypass the published connector entirely and build a custom connector that authenticates using the API key or client credentials directly.
This approach eliminates the human identity from the connection entirely. The custom connector authenticates as the application, not as a user, which means no service account to govern, no delegated permission to manage, and no risk of a flow breaking because a user account was disabled.
The tradeoff is build and maintenance overhead. Custom connectors require someone to build and maintain the connector definition, manage API key rotation, and keep pace with any changes to the underlying API. In a law firm environment where IT teams are often lean, that ongoing maintenance commitment is a real cost to weigh against the governance benefit.
Use this approach when the third-party API supports app-only authentication, when the published connector’s limitations are blocking you beyond just the service principal issue, and when your team has the capacity to build and maintain a custom connector over time.
Direct HTTP Actions in Power Automate
If the third-party service exposes a REST API, Power Automate’s built-in HTTP action can call it directly using an API key or OAuth client credentials – bypassing the published connector entirely without building a full custom connector. This is the fastest path to eliminating a delegated identity from a specific API call, and it requires no additional infrastructure.
The limitation is maintainability. Direct HTTP actions are harder to reuse across flows, lack the discoverability of a proper connector, and put the burden of API construction – headers, authentication tokens, request bodies – directly in the flow definition. For simple, infrequent API calls this is a reasonable tradeoff. For complex integrations or calls made across many flows, a custom connector is the better long-term investment.
Use this approach for straightforward, low-volume API calls where speed of implementation matters more than long-term maintainability.
Azure Functions as Middleware
Azure Functions is a serverless compute service that lets you write lightweight code – in Python, C#, JavaScript, or other languages – that runs on demand in response to a trigger. As a middleware option, you write a Function that handles authentication to the third-party service and exposes a simple HTTP endpoint. Your Power Automate flow calls the Function, the Function handles the third-party authentication and API call, and returns the result. The flow never authenticates directly to the third-party service.
This gives you the credential isolation of a middleware approach without the full overhead of Azure API Management. Azure Functions is lower cost, faster to set up, and sufficient for many integration scenarios. The tradeoff compared to APIM is that you’re writing and maintaining code rather than configuration, and you don’t get the broader API gateway capabilities – centralized policy enforcement, rate limiting, developer portal, and detailed analytics – that APIM provides.
Use this approach when you need middleware for a specific integration and don’t need a full API gateway, and when your team is comfortable writing and maintaining code in an Azure Functions environment.
Azure API Management as Middleware
Azure API Management (APIM) is a Microsoft Azure service that acts as a gateway between your applications and the APIs they call. Rather than having each flow authenticate directly to a third-party service, APIM sits in the middle – managing authentication, logging calls, enforcing policies, and presenting a consistent interface to the flows calling through it.
In this model, your Power Automate flow calls an APIM endpoint using a service principal or API key. APIM handles the translation and manages authentication to the third-party service on the back end. The flow never authenticates directly to the third-party connector at all. Credentials for third-party services live in APIM, not in Power Automate connections, giving you centralized credential management and a single audit point for all calls passing through.
For law firms with multiple flows touching the same third-party services, APIM as a middleware layer consolidates what would otherwise be a sprawl of individual connector connections each carrying their own credentials. You also gain the ability to swap out the underlying third-party service without changing the flows that call through it.
The cost is complexity and infrastructure overhead. APIM is not the right answer for a single flow with one third-party connection. It becomes increasingly attractive as the number of flows, connectors, and third-party services grows and centralized governance becomes a priority.
Use this approach when you have multiple flows connecting to the same third-party services, when centralized credential management and auditability are firm requirements, and when your team has the Azure architecture capability to build and maintain the middleware layer.
Azure Logic Apps
Logic Apps is Microsoft’s developer-oriented workflow automation platform that sits alongside Power Automate in the Azure ecosystem. While Power Automate is optimized for citizen developers and business users, Logic Apps is built for engineering teams and supports managed identities natively – meaning it can authenticate to supported services using an Entra ID-managed identity without any stored credential at all.
In some cases, a flow that hits a service principal limitation in Power Automate can be rebuilt in Logic Apps and the authentication problem disappears entirely, because the Logic Apps connector for the same service supports app-only auth where the Power Automate connector does not. It is worth checking connector parity before committing to a more complex middleware approach.
The tradeoff is that Logic Apps requires engineering capability to build and maintain, sits outside the Power Platform governance model your firm may have established, and adds Azure infrastructure to manage. It is not a fit for citizen-developer-built flows, but for IT-owned automation touching sensitive matter processes it may be the cleaner long-term solution.
Use this approach when the equivalent Logic Apps connector supports managed identity or app-only auth, and when the flow is IT-owned and complex enough to justify moving off the Power Platform stack.
Choosing the Right Approach
No single workaround is universally correct. A useful way to work through the decision:
Start by checking whether the third-party service’s API supports app-only authentication. If it does, a custom connector, direct HTTP action, or Logic Apps managed identity may solve the problem cleanly without any service account. If it doesn’t, a service account with delegated credentials is likely your most practical path – with the governance controls to match.
If you have multiple flows hitting the same third-party services and credential sprawl is becoming a management problem, Azure Functions or APIM as middleware starts to make sense. If your firm already has an integration platform – MuleSoft, Boomi, Workato, or similar – in its environment for other purposes, routing Power Automate flows through that existing infrastructure may be simpler than standing up new Azure middleware.
The goal in every case is the same: minimize the number of human identities embedded in automated flows, govern the ones you can’t eliminate, and make sure every connection is owned, documented, and monitored.
Law Firm Considerations
The technical workarounds described above are available to any organization running Power Automate. In a law firm, the choice between them carries additional weight because the flows most likely to hit this problem are also the flows most likely to touch sensitive matter data, client information, or regulated processes. A few considerations specific to the legal environment are worth calling out explicitly.
Auditability is not optional. In a law firm, knowing what acted on a document, when, and under what identity is not just an IT concern – it can be a professional responsibility concern. When a flow runs under a service account with delegated credentials, the audit trail in the third-party system shows that service account’s identity, not the attorney or staff member who triggered the flow. Before committing to a workaround, map out what the audit record looks like end to end across every system the flow touches – Power Automate, the third-party service, your DMS, and any intermediate layer. Make sure that record satisfies both your internal governance requirements and any obligations to clients about how their matter data is handled.
Service account ownership needs to be explicit and documented. A service account that isn’t clearly owned by a named team is a governance liability. In law firms where IT turnover happens and matters span years, a service account created by someone who has since left – with credentials known only to that person – is a ticking clock. Every service account used in automation should have a named owner, credentials stored in a firm-managed secrets store, a documented rotation schedule, and a formal offboarding process that ensures the account doesn’t become an orphan when personnel change.
Licensing costs add up at scale. Service accounts require Microsoft 365 licenses, and depending on the third-party services involved, may require additional per-seat licensing from the connector publisher. In a large firm with many flows and many service accounts, this becomes a meaningful budget line. It is also an argument for pursuing the custom connector, HTTP action, or middleware approaches where the third-party API supports them – eliminating the delegated identity eliminates the licensing dependency entirely.
Flow failure at the wrong moment has matter-level consequences. In most industries a broken automation flow creates an IT ticket. In a law firm it can halt a time-sensitive matter process – signature requests don’t go out, documents don’t get filed, deadline-driven workflows stop mid-execution. Flows that touch matter processes need to be treated as operational dependencies, not background utilities. Build monitoring and alerting around service account health and flow run history, define a clear on-call response process for critical flow failures, and test your recovery procedure before you need it.
Power Automate connections are easy to create and easy to forget. Connections – the stored credentials that sit behind a connector – accumulate quickly in environments where both IT professionals and citizen developers are building flows. In a law firm, a connection created by a paralegal using their personal credentials to automate a matter workflow is a governance problem waiting to surface. Establish a process that inventories active connections across your Power Platform environment, maps each connection to its owning team, and reviews them on a regular cadence. Connections using personal user credentials rather than purpose-built service accounts should be flagged and migrated.
The citizen developer dynamic requires guardrails, not just guidance. Law firms increasingly encourage attorneys and legal operations staff to build their own automations in Power Automate. That’s a legitimate and valuable capability; but it creates a real risk of ungoverned service principal workarounds proliferating across the environment. A paralegal who discovers that their personal credentials work where a service principal doesn’t will use their personal credentials, and that connection will run unattended long after they’ve forgotten about it. Your Power Platform governance program needs to address this explicitly – not by restricting citizen development, but by providing approved, pre-built connection templates that use properly governed service accounts, so the path of least resistance is also the governed path.
Governance Recommendations
The workarounds in this article solve the technical problem. Governance is what keeps those workarounds from becoming the next problem. The following recommendations apply regardless of which approach your firm chooses, but are particularly important when service accounts or stored credentials are involved.
Maintain a connection inventory. Every Power Automate connection in your environment, the stored credential behind every connector, should be catalogued. At minimum, the inventory should capture the connection owner, the identity it authenticates as, the connectors and flows using it, and the date it was last reviewed. This doesn’t need to be complex, but it does need to exist. Without it, you have no reliable way to assess the blast radius when a service account is disabled or a credential is compromised.
Treat service accounts like infrastructure, not like user accounts. Service accounts purpose-built for automation should be provisioned, managed, and decommissioned through a formal process – the same way you would manage a server or an application registration. That means named ownership, documented purpose, credential storage in a secrets management solution such as Azure Key Vault, a defined rotation schedule, and a decommissioning process that ensures the account is disabled and its connections are migrated when it is no longer needed.
Store credentials in Azure Key Vault, not in flow definitions. It is technically possible to embed API keys and credentials directly in Power Automate flow definitions or environment variables. Don’t. Azure Key Vault provides centralized, auditable secrets management with access controls, rotation support, and logging. Flows and custom connectors should retrieve credentials from Key Vault at runtime rather than carrying them as static values. This applies to API keys, client secrets, and any other credential used in an integration.
Build flow ownership into your Power Platform governance model. Every flow that runs unattended in a production environment should have a named owner – a team, not an individual – responsible for its health, its connections, and its behavior. Flows without clear ownership are the ones that break silently and go unnoticed until a matter deadline surfaces the failure. Include flow ownership in your broader Power Platform Center of Excellence governance model, and build a regular review cadence that checks for orphaned flows, expired connections, and flows still running under personal user credentials.
Test failure scenarios before they happen in production. For every critical flow, define what happens when its connection breaks. Disable the service account in a test environment and observe the failure mode. Is there an alert? Does the flow fail gracefully or silently? Is there a notification to the flow owner? Is there a documented recovery procedure? In a law firm where flows touch matter processes, the answer to these questions should be known before a failure occurs in production, not discovered during one.
Align your Power Platform governance with your broader security program. Service accounts created for Power Automate connections should be visible to your security team, included in your privileged identity reviews, and subject to the same monitoring as other non-human identities in your environment. A service account that bypasses MFA via a Conditional Access exclusion is a potential attack vector – it should be treated as one, with compensating controls including sign-in monitoring, geographic restrictions, and regular access reviews.
Document the why, not just the what. For every non-standard authentication workaround – every service account, every custom connector, every middleware integration – document why that approach was chosen over the alternatives. Six months from now, the person inheriting the environment needs to understand not just what is running, but why it was built that way. In a law firm context where systems need to be defensible to clients, auditors, and firm leadership, that documentation is part of the governance record.
Conclusion
Service principals are the right default identity for unattended automation in Microsoft 365. They are more secure than service accounts, easier to govern than delegated user credentials, and purpose-built for the kind of non-interactive flows that modern law firm operations increasingly depend on. The problem is not with service principals – it is with the assumption that they work everywhere.
Most third-party Power Automate connectors were built around delegated user authentication. That is not a bug or an oversight – it reflects how OAuth 2.0 delegated flows work and how most connector publishers have chosen to implement them. Understanding that constraint is the first step to architecting around it deliberately rather than discovering it the hard way when a production flow fails.
The workarounds available to you – service accounts with delegated credentials, custom connectors, direct HTTP actions, Azure Functions, APIM, and Logic Apps – each make different tradeoffs between implementation complexity, governance overhead, and long-term maintainability. None of them is universally correct. The right choice depends on what the third-party API supports, how many flows are involved, and what your firm’s security and operational posture requires.
In a law firm, those choices carry more weight than in most environments. Flows that touch matter data, trigger document actions, or drive deadline-sensitive processes are not background utilities – they are operational dependencies. The identity behind them, the audit trail they produce, and the governance controls around them are not just IT concerns. They are part of how your firm demonstrates to clients, regulators, and firm leadership that sensitive matter processes are running under appropriate controls.
The firms that get this right are the ones that treat the service principal limitation not as a one-time technical problem to solve and move on from, but as a prompt to build a durable governance model for how non-human identities are provisioned, managed, and monitored across their entire automation environment. That model pays dividends well beyond Power Automate – it becomes the foundation for governing every automated process that touches matter data, regardless of what platform it runs on.