Your finance team's Power Automate flow has been running smoothly for six months — pulling invoice data from SharePoint, enriching it through a custom connector to your ERP, and posting summaries to a Teams channel. Then one day, the flow author leaves the company. IT disables their account. The flow breaks. Worse, you discover the flow was running under their personal credentials the entire time, and the connection to the ERP system was storing their password in plain text inside a shared environment. Now you're scrambling to rebuild something that should have been architected properly from day one.
This is not a hypothetical. It's one of the most common failure modes in enterprise Power Automate deployments, and it happens because the path of least resistance — using your own credentials, clicking "New Connection," and getting on with your life — creates hidden technical debt that compounds until it breaks catastrophically. Security in Power Automate isn't just about preventing data leaks; it's about building flows that survive personnel changes, scale across teams, and remain auditable when someone inevitably asks, "Wait, who has access to what?"
By the end of this lesson, you will be able to design and implement a production-grade security posture for Power Automate environments. You'll understand the credential management options available to you, know how to implement connection references correctly for ALM-safe deployments, configure DLP policies that protect sensitive data without grinding your automation program to a halt, and troubleshoot the common security failures that catch even experienced practitioners off guard.
What you'll learn:
This lesson assumes you are already comfortable building multi-step flows with conditional logic, error handling, and HTTP actions. You should have a working understanding of Azure Active Directory (now Entra ID) concepts including service principals, app registrations, and OAuth 2.0 flows. Familiarity with Power Platform environments and solutions is helpful but we'll cover the relevant mechanics as we go. You should also have access to a Power Platform environment where you have System Administrator or Environment Admin privileges — you cannot implement most of what we cover here without administrative access.
Before you can secure credentials, you need to understand what Power Automate is actually doing with them. Most practitioners have a fuzzy mental model here, and that fuzziness is where security vulnerabilities hide.
When you create a connection in Power Automate — say, to SharePoint or SQL Server — you're creating a stored credential object. Specifically, you're creating a record in the Dataverse table connectionreferences or the underlying connection store, depending on how the connection was created. That record contains an encrypted OAuth refresh token, a username/password pair, or an API key, depending on the connector type.
Here's what's critical to understand: a connection is always owned by a user identity. When you create a SharePoint connection using your own Microsoft 365 account, that connection is running as you. Every API call the flow makes through that connection is authenticated using your OAuth token, refreshed automatically in the background using the stored refresh token. When your account is disabled, the refresh token can no longer be exchanged for a new access token, and the connection breaks.
The connection itself lives in the Power Platform environment's connection store. Other users can be granted access to use the connection (the "Can use" permission), but the underlying authentication is still happening as the original owner. This is what creates the dependency on individual employees.
Power Automate flows have a concept of an "owner" (the user who runs the flow by default) that's distinct from who triggers the flow. When you share a flow as "Run Only," the connections can be configured to use either:
This second option is seductive because it seems to solve the "everyone needs their own connection" problem, but it simply moves the credential dependency rather than eliminating it. You now have a single set of credentials doing everything on behalf of many users, which creates both a security risk (one account can see everything) and a breaking point (if that owner account changes).
OAuth tokens expire. Refresh tokens have longer lifespans — typically 90 days for Microsoft 365 accounts — but they can be revoked by:
When any of these events occurs, every flow using that person's connection silently begins failing at the next token refresh attempt. You won't get a warning ahead of time. The flow will simply start returning 401 Unauthorized errors, and if your error handling isn't robust, these failures may go undetected.
Warning: A common anti-pattern is creating a "service account" Microsoft 365 user (like
powerautomate@yourdomain.com) and building connections under that account. This solves the "employee leaves" problem but creates new issues: the account still needs a license, still has token expiration, and still requires password management. Microsoft's licensing guidance has also changed to restrict this pattern for certain connector types. Use proper service principals instead, which we cover in the next section.
The correct solution to credential lifecycle management in production flows is to stop using human credentials entirely for system-to-system automation. Service principals and managed identities are the proper tools for this.
An Azure AD / Entra ID app registration creates a non-human identity that can authenticate to services using certificate credentials or client secrets. Unlike user accounts, app registrations don't have expiring refresh tokens in the same way — they use client credentials flow (OAuth 2.0 grant type client_credentials), which exchanges a client secret or certificate for an access token directly.
To create an app registration for Power Automate:
PowerAutomate-InvoiceProcessing-ProdAfter creation, go to Certificates & secrets and create a client secret. Record the secret value immediately — you will not be able to retrieve it again. Set a long expiration (24 months is the maximum currently), and make sure you have a process to rotate it before expiration.
Now you need to grant this principal permissions to the resources it needs. For SharePoint:
API Permissions > Add a permission > Microsoft Graph > Application permissions
- Sites.ReadWrite.All (if it needs to write to any site)
- or Sites.Selected (strongly preferred — limits access to specific sites)
For Sites.Selected, you then need to grant site-level permissions through the SharePoint API or PnP PowerShell:
# Using PnP PowerShell to grant the app registration access to a specific SharePoint site
Connect-PnPOnline -Url "https://yourtenant.sharepoint.com" -Interactive
Grant-PnPAzureADAppSitePermission `
-AppId "your-app-registration-client-id" `
-DisplayName "PowerAutomate-InvoiceProcessing-Prod" `
-Site "https://yourtenant.sharepoint.com/sites/Finance" `
-Permissions Write
This is dramatically more secure than Sites.ReadWrite.All — if the credentials are ever compromised, the blast radius is limited to specifically granted sites rather than your entire SharePoint tenant.
For connectors that support service principal authentication, you'll create the connection using the client ID and secret. The SharePoint connector, for example, supports service principal auth when you choose "Service Principal Authentication" during connection creation.
However, not all connectors support service principal authentication natively. For those that don't, you have two options:
Option 1: HTTP with Azure AD connector — Make direct REST API calls using the "HTTP with Azure AD" connector or the standard "HTTP" connector with a manually obtained bearer token. This gives you full control but requires you to handle the token acquisition yourself.
Option 2: Custom connector with certificate auth — Build a custom connector that wraps the target API and handles its own authentication. The custom connector can use OAuth 2.0 client credentials behind the scenes, exposing a simpler interface to the flow.
If your flow is calling Azure services — Azure SQL, Key Vault, Service Bus, Blob Storage — managed identities are an even better option than app registrations because there are no secrets to manage at all. The identity is tied to the Azure resource and rotated automatically.
Power Automate Premium supports managed identity authentication for several Azure connectors. When creating a SQL Server connection, for example, you can choose "Managed Identity" as the authentication type. The underlying Power Platform infrastructure handles the identity assertion, and you never see a credential.
For Azure Key Vault specifically, a best practice pattern is:
Key Vault Secrets User RBAC role on the vaultThis means your flow definition never contains a static credential. The only thing in the flow is the Key Vault URL and secret name — neither of which is sensitive on its own.
Initialize variable: apiKey
Type: String
Value: [Key Vault - Get Secret output: value]
HTTP Action:
Method: POST
URI: https://api.yourerpSystem.com/v2/invoices
Headers:
Authorization: Bearer @{variables('apiKey')}
Content-Type: application/json
Body: @{body('Parse_JSON')}
Tip: Rotate Key Vault secrets on a schedule rather than waiting for them to expire. A 90-day rotation cycle with a 30-day overlap (old secret still valid for 30 days after the new one is created) gives you time to update any systems that use the old secret before it's revoked.
If you've ever exported a solution from a development environment and imported it into production, only to have every flow show "Connection Invalid," you've run into the connection reference problem. Understanding how connection references work — and building them into your solution architecture from the start — is what separates flows that can actually be deployed through a proper ALM pipeline from flows that can only exist in the environment they were born in.
A connection reference is an abstraction layer between a flow and the actual connection it uses. Think of it as a pointer: the flow says "I need a SharePoint connection" and the connection reference resolves which specific connection object fulfills that need. In a development environment, the connection reference points to a developer's SharePoint connection. In production, the same connection reference points to the service principal-authenticated connection.
Without connection references, the flow hardcodes a reference to a specific connection ID — a GUID that only exists in the environment where it was created. Move the flow to a different environment, and that GUID is meaningless.
Connection references must be created inside a solution. This is non-negotiable for ALM. If you build a flow outside of a solution (in the default "My Flows" space), it cannot have proper connection references and will not survive environment migration cleanly.
To create a connection reference:
When you add a trigger or action to a flow within a solution, and you select a connector, Power Automate will prompt you to create or select a connection reference. If you skip this and use a "personal connection" instead, you've already broken your ALM story.
The connection reference gets exported as part of the solution ZIP file. When you import the solution into a new environment, the import wizard will ask you to map each connection reference to a connection that exists in the target environment. This is where the mapping happens.
Connection references solve the credential mapping problem, but they don't solve the configuration difference problem. Production might hit a different SQL server than development. The SharePoint site URL might differ between environments. For this, you combine connection references with environment variables.
An environment variable stores a configuration value that can differ per environment. Your flow reads the variable at runtime rather than having the value hardcoded.
SharePoint List Items - Get Items:
Site Address: @{parameters('sp_invoices_site_url')}
List Name: @{parameters('sp_invoices_list_name')}
Where sp_invoices_site_url and sp_invoices_list_name are environment variables defined in your solution. When you import the solution into production, you set production values. When you import it into QA, you set QA values. The flow definition is identical in all environments.
Warning: There is a subtle bug-prone area here: if you reference an environment variable that hasn't been set in the target environment, Power Automate will use the default value from the solution package — which is whatever was in the development environment when the solution was exported. This can lead to production flows silently hitting development resources. Always verify environment variable values after import, and consider building a post-deployment validation check.
This distinction matters enormously for security. When you import an unmanaged solution into an environment, users in that environment can modify the flow. When you import a managed solution, the flow becomes read-only — users can see it and run it, but they cannot modify the flow definition.
In production, you should almost always be deploying managed solutions. This prevents ad-hoc modifications that would bypass your change management process. If someone needs to make a change, they make it in the development environment, go through the ALM pipeline, and deploy a new managed solution version. There's an audit trail. There are no surprise "quick fixes" that nobody documented.
For teams doing real CI/CD, the Power Platform CLI (pac) is your tool for automating solution export, unpacking, and import:
# Authenticate to your development environment
pac auth create --url https://yourorg.crm.dynamics.com --name dev-auth
# Export the solution as managed (for production deployment)
pac solution export \
--name InvoiceProcessingSolution \
--path ./solutions/InvoiceProcessingSolution.zip \
--managed true \
--environment https://yourorg.crm.dynamics.com
# Import into production
pac solution import \
--path ./solutions/InvoiceProcessingSolution.zip \
--environment https://yourprodorg.crm.dynamics.com \
--connection-variables @connection-vars-prod.json
The connection-variables-prod.json file maps connection reference logical names to connection IDs in the production environment:
{
"shared_sharepointonline_ref": "/providers/Microsoft.PowerApps/apis/shared_sharepointonline/connections/prod-sharepoint-svc-principal",
"shared_sql_ref": "/providers/Microsoft.PowerApps/apis/shared_sql/connections/prod-sql-managed-identity"
}
This is how you get repeatable, auditable deployments. The connection IDs in this file reference connections that have been pre-created in the production environment using the appropriate service principal or managed identity credentials. The file itself should be stored in your secrets management system (Azure Key Vault, GitHub Secrets, Azure DevOps secure files), not committed to source control in plain text.
Data Loss Prevention policies in Power Platform are a blunt instrument in the hands of an overzealous administrator. I've seen DLP configurations that locked down environments so tightly that legitimate business automation became impossible, causing shadow IT to explode as users found workarounds. I've also seen DLP policies so permissive they might as well not exist. Getting this right requires understanding both the technical mechanics and the governance philosophy.
A DLP policy operates at the connector level, not the data level. This is the most important thing to understand about it. DLP cannot inspect the content of data flowing through a connector and decide to block or allow it based on what the data contains. It can only allow or block specific connectors from being used together in the same flow.
Each connector is classified into one of three groups:
A flow is blocked by DLP if it uses at least one Business connector AND at least one Non-Business connector. The goal is to prevent a flow from, say, reading sensitive customer data from Dynamics 365 (Business) and posting it to a personal Dropbox account (Non-Business).
Here's the edge case that trips up almost every enterprise DLP configuration: the HTTP connector.
The HTTP connector allows a flow to make arbitrary web requests to any URL. From a DLP perspective, this is a gaping hole. If you put HTTP in the Business group alongside your Dynamics 365 connector, you've effectively allowed flows to exfiltrate your business data to any endpoint on the internet, as long as they use the HTTP connector to do it.
If you put HTTP in the Blocked group, you've broken all flows that need to call external REST APIs — which in many organizations is a significant chunk of their automation portfolio.
The pragmatic solution is to use the HTTP with Azure AD connector for calls to Azure and Microsoft services (this connector requires authentication and is therefore more controlled), and to use custom connectors for calls to external systems. Custom connectors can themselves be classified as Business or Non-Business, and their URLs are locked to specific hosts defined in the connector definition. A custom connector for your ERP system can only ever call your ERP system's URL — it can't be redirected to a malicious endpoint.
DLP Policy Structure for a Typical Enterprise Environment:
├── Business Group
│ ├── SharePoint
│ ├── SQL Server
│ ├── Dynamics 365
│ ├── Teams
│ ├── Outlook
│ ├── HTTP with Azure AD
│ └── Custom Connectors (ERP, ITSM, etc.)
├── Non-Business Group
│ ├── Twitter
│ ├── Instagram
│ └── Other consumer connectors
└── Blocked Group
├── HTTP (raw)
└── Any connectors with no legitimate business use
Tip: Blocking the raw HTTP connector is the right call for most environments, but it requires organizational commitment to building proper custom connectors for external API calls. Budget for this work — custom connectors need to be maintained, and their certificates and secrets need rotation cycles. If your team doesn't have the capacity for this, a pragmatic alternative is to allow HTTP only in a dedicated "integration" environment with elevated monitoring, while blocking it in general-purpose environments.
DLP policies can be scoped at two levels:
Tenant-level policies apply to all environments except those explicitly excluded. These should encode your organization's baseline security requirements — the rules that apply everywhere, no exceptions. A tenant-level policy might block all consumer social media connectors and block the raw HTTP connector.
Environment-level policies apply only to the specific environments you assign them to. These let you add additional restrictions or relax restrictions (within the bounds of what tenant-level allows) for specific environments. A development environment might allow a wider range of connectors for experimentation. A PCI-scoped environment might have dramatically stricter restrictions.
The interaction between policies is additive: if a tenant policy blocks connector X, no environment policy can unblock it. This is the right model — your tenant-level policy is your floor, and environment policies can only raise the bar.
Tenant Policy (applies everywhere):
Blocked: HTTP, Twitter, Instagram, Personal Gmail
Environment Policy (applies to Finance-Prod):
Business: SharePoint, SQL, Dynamics 365, ERP-Custom-Connector
Non-Business: Everything else not listed in Business
Effective result in Finance-Prod:
Blocked: HTTP, Twitter, Instagram, Personal Gmail (from tenant policy)
Restricted to Business group connectors for any flow that also uses SQL or Dynamics
Introduced in late 2022, endpoint filtering allows DLP policies to restrict specific connectors to only a subset of endpoints. This is extraordinarily useful for the SharePoint connector, for example — you can restrict SharePoint flows to only connect to your tenant's SharePoint sites, preventing someone from building a flow that reads your company's SharePoint data and copies it to an external SharePoint tenant they control.
Configure endpoint filtering in the Power Platform Admin Center under Policies:
https://yourtenant.sharepoint.com/*Any flow in this environment that attempts to use the SharePoint connector to connect to a URL not matching this pattern will be blocked at runtime.
Similar filtering is available for SQL Server (to restrict to specific server hostnames), HTTP with Azure AD (to restrict to specific Azure tenants), and several other connectors. This is one of the most underutilized security controls in Power Platform, and it provides a qualitatively different level of protection compared to connector-group-level DLP alone.
For connectors in the Business group, you can also control which actions within a connector are permitted, not just whether the connector can be used. This is available for select connectors and allows you to, for example, allow SharePoint read operations but block SharePoint write or delete operations.
This is particularly useful for connectors where you need to allow monitoring/audit-type automation (which only reads data) but want to prevent data modification or exfiltration through bulk export actions.
Building secure flows is half the battle. Knowing when something goes wrong — and having the information you need to respond — is the other half.
All administrative operations on Power Platform — DLP policy changes, environment creation, solution imports, connection creation — are logged to the Microsoft 365 compliance portal's audit log. This is often overlooked by organizations that are disciplined about auditing their Azure and Microsoft 365 workloads but forget that Power Platform is a separate audit stream.
To enable Power Platform audit logging:
You can then query the audit log using the Search-UnifiedAuditLog PowerShell cmdlet or the compliance portal UI:
# Query Power Platform audit events for the last 7 days
$startDate = (Get-Date).AddDays(-7).ToString("MM/dd/yyyy")
$endDate = (Get-Date).ToString("MM/dd/yyyy")
Search-UnifiedAuditLog `
-StartDate $startDate `
-EndDate $endDate `
-RecordType PowerApps `
-Operations "DeleteEnvironment,ExportSolution,ImportSolution,CreateConnection" `
-ResultSize 500 |
ConvertTo-Json |
Out-File audit_report.json
The operations you should actively monitor for in a security context:
ImportSolution — someone deployed something to productionExportSolution — someone exported a solution (potential data exfiltration of flow definitions)CreateDlpPolicy, UpdateDlpPolicy — someone modified a DLP policyCreateConnection — a new connection (credential) was createdUpdateFlowOwner — flow ownership changed handsFor operational monitoring of flows themselves (not administrative actions), the Power Platform Admin Center offers flow analytics at the environment level. You can see run counts, failure rates, and performance metrics across all flows in an environment.
For production flows, you should also be implementing your own run history logging. The built-in run history has a 28-day retention window. If you need longer retention for compliance or debugging purposes, use the "When a flow run fails" trigger (available through the Monitoring connector) to capture failure details and write them to a Dataverse table or Azure Log Analytics workspace.
Flow: Log_Failed_Flows_to_Analytics
Trigger: Power Platform for Admins - Get Flow Run as Admin (scheduled, every 15 minutes)
Filter: Status equals 'Failed'
For each failed run:
- Parse the error details
- Write to Azure Log Analytics using HTTP Data Collector API
- If error count > threshold, send alert to Teams channel
If your organization uses Azure AD Conditional Access policies, be aware that these policies apply to Power Automate just like they apply to any other Microsoft 365 application. A conditional access policy that requires MFA for access to the Power Platform app will apply when users sign into the maker portal — but it will NOT apply to automated flow runs.
This is actually the correct behavior: you don't want an automated flow to be blocked because it can't complete an MFA challenge. Service principal-based flows aren't subject to user-facing conditional access policies. However, flows running under user credentials (the problematic personal connection approach we discussed earlier) can have their token refresh blocked if a conditional access policy changes the requirements for that user.
This is another argument for service principal authentication: conditional access policies for service principals use different controls (IP-based restrictions, certificate requirements) that are more appropriate for automated workloads.
Beyond DLP policies, there's an application-level security layer you need to think about when flows process truly sensitive data — PII, financial records, health information.
Power Automate doesn't have built-in field-level encryption for flow variables, but you can implement a pattern where sensitive values are retrieved from Key Vault, used transiently within the flow, and never logged or persisted in a readable form.
The key technique is using the "Secure Inputs" and "Secure Outputs" toggles on individual actions. When you enable these settings on an action, that action's input and output data is masked in the run history — it shows as ***REDACTED*** instead of the actual value. This prevents someone with access to the run history from reading sensitive values that flowed through the action.
To enable this: In any action's settings (the three-dot menu > Settings), toggle "Secure Inputs" and "Secure Outputs" to On.
This should be mandatory for:
Note that secure outputs have a cascade effect — if Action A has secure outputs, and Action B uses Action A's output, Action B must also have secure inputs enabled, otherwise the value becomes visible again in the run history of Action B.
A subtler issue: variables in Power Automate are stored in memory during the flow run, but their values at each update point are logged in the run history unless the Set Variable action has "Secure Inputs" enabled. Initialize a variable to store a sensitive value only if you need to reference it multiple times. If you only use it once, pass it directly as a dynamic expression rather than storing it in a variable — this reduces the number of places the value can appear in logs.
// Anti-pattern: storing sensitive value in an accessible variable
Initialize variable: customerSSN = @{body('Get_Customer_Record')['ssn']}
// This SSN is now visible in the run history for the Initialize Variable step
// Better pattern: use the value directly in the action that needs it
HTTP Action:
Body: {
"ssn": "@{body('Get_Customer_Record')['ssn']}",
"action": "verify_identity"
}
// Enable "Secure Inputs" on this action
// The SSN is only in the run history of this one action, which is masked
In this exercise, you'll take a deliberately insecure flow and rebuild it to production security standards. You'll need a Power Platform environment where you are a System Administrator, and you'll need permissions to create app registrations in your Azure AD tenant.
Scenario: You have a flow that reads employee expense reports from a SharePoint list, filters for reports over $5,000, and sends a summary email to the finance team via Outlook. The flow was built by an HR analyst using their personal credentials.
Part 1: Create a Service Principal
PA-ExpenseReporting-Prodpa-expense-reporting-client-secretRead permission on only the SharePoint site containing the expense reports list (use Grant-PnPAzureADAppSitePermission)Mail.Send delegated permission via a registered app, or to use the Microsoft Graph API directly with Mail.Send application permission on the service principalPart 2: Rebuild the Flow in a Solution
Create a new solution named ExpenseReporting
Inside the solution, create two environment variables:
sp_expense_site_url (type: String, default value: your SharePoint site URL)expense_approval_threshold (type: Number, default value: 5000)Create two connection references:
SharePoint_ServicePrincipal using SharePoint connector with service principal authGraph_SendMail using the Microsoft Graph custom connector (or HTTP with Azure AD) for sending emailRebuild the flow inside the solution using these connection references and environment variables. The flow should:
sp_expense_site_url environment variableexpense_approval_threshold environment variablePart 3: Configure a DLP Policy
Part 4: Validate Your Work
After completing the rebuild, verify:
Cause: Flow is using user credential-based connection, user's refresh token expired or was revoked. Solution: Migrate to service principal authentication. Short-term, re-authenticate the connection in the maker portal. Long-term, rebuild using the patterns in this lesson.
Cause: A DLP policy was created or modified. New policies take effect within 24 hours but are sometimes applied within minutes. The flow's connections are now in incompatible groups. Solution: Check the Power Platform Admin Center audit log for recent DLP policy changes. In the Admin Center, use the "Test" feature on the DLP policy to verify which connectors are blocked. If the block is unintentional, adjust the policy. If the block is intentional, the flow needs to be redesigned to comply.
Cause: The connection being referenced doesn't exist in the target environment, or the connection ID in the import mapping doesn't match an existing connection. Solution: Before importing, pre-create all required connections in the target environment. Then during import, map each connection reference to the appropriate pre-created connection. Alternatively, use the Power Platform CLI with a properly constructed connection-variables file.
Cause: When an action has secure outputs enabled, downstream expressions that reference its output will receive a null or empty value in some contexts, because the output is masked. Resolution: This is expected behavior. The secure output masking applies to the run history viewer only, not to the actual runtime execution. Expressions in downstream actions still receive the actual values during execution. If your downstream action's expression is failing, the issue is the expression syntax, not the secure outputs setting.
Cause: Not all Power Platform connectors support service principal authentication. Some connectors require delegated (user) permissions by design. Solution: For connectors that don't support service principal auth, use the "HTTP with Azure AD" connector to call the underlying API directly using application permissions, or build a custom connector that handles the authentication internally. Accept that some connectors will require a dedicated service account user — manage this by creating a proper licensed service account, documenting it as a service identity, and ensuring it's not subject to accidental deletion.
Cause: If the target environment already had a previous version of the solution installed with different environment variable values, the import may or may not overwrite the existing values depending on the import mode and whether the variables are "Current values" vs. "Default values." Solution: After every solution import to a non-development environment, explicitly verify and set environment variable current values through the Power Platform Admin Center or via the Power Platform CLI:
pac env update-settings \
--environment https://yourprodorg.crm.dynamics.com \
--setting sp_expense_site_url "https://yourtenant.sharepoint.com/sites/Finance"
Securing Power Automate flows in production is a systems problem, not a checkbox problem. The technical controls we've covered — service principals, connection references, DLP policies, managed solutions, audit logging — are only effective if they're implemented as a coherent architecture from the start. Bolting security on after the fact is painful and incomplete.
The core principles to carry forward:
Eliminate personal credential dependencies by using service principals and managed identities for all system-to-system automation. The "it works with my account" solution is not a production solution.
Build for ALM from day one by working inside solutions, using connection references, and using environment variables for configuration. Flows that can't be promoted through environments cleanly cannot be properly governed.
Use DLP policies as a data architecture tool, not just a restriction mechanism. Thoughtfully designed DLP policies encode your organization's data classification decisions and make them enforceable at the infrastructure level. This requires IT, security, and business stakeholders to agree on what "business data" means before you start clicking buttons in the admin center.
Treat run history as a potential security exposure and use secure inputs/outputs on any action handling sensitive values. Audit access to the maker portal and run history as you would audit access to the underlying data systems.
Monitor and alert proactively. A flow failure is often the first symptom of a security event (credential compromise, DLP policy violation, unauthorized access change). Build monitoring flows that detect failure patterns and surface them to the right teams before users file helpdesk tickets.
Next Steps for Continued Learning:
The discipline required to secure Power Automate properly is exactly the same discipline that separates maintainable, scalable automation programs from sprawling, ungovernable click-and-forget flows. Invest in this architecture now, and you won't be the person getting paged at 2 AM because a departed employee's refresh token expired.
Learning Path: Flow Automation Basics