Data > Credentials in Power Automate

If you have ever built a Power Automate desktop flow that needs to log in to a website, connect to a database, or authenticate with an API, you have probably encountered the Data > Credentials section. This is where Power Automate stores reusable login information so your flows can authenticate without hardcoding passwords into actions.

This guide covers how the credential system works, what types of credentials you can store, common pitfalls that cause flows to fail silently, and how the credential model compares to newer approaches used by AI desktop agents.

Where to Find Data > Credentials

In Power Automate Desktop, the credential store lives under the Data menu in the flow designer. The navigation path is:

1. Open Power Automate Desktop
2. Edit any desktop flow (or create a new one)
3. In the left sidebar or top menu, click Data
4. Select Credentials

This opens the credential manager where you can create, edit, and delete stored credentials. Each credential entry consists of a name, a username, and a password (or equivalent secret). Flows reference credentials by name, so renaming a credential will break any flow that uses it.

Credential Types and Storage

Power Automate Desktop supports several credential types depending on your licensing and environment:

| Credential Type | Storage Location | Encryption | Sharing | Use Case | |---|---|---|---|---| | Local credentials | Windows Credential Manager (DPAPI) | Machine-level, user-bound | Not shareable | Personal desktop flows | | Environment credentials | Dataverse (Power Platform) | Server-side, Azure AD scoped | Team-shareable | Shared production flows | | Connection references | Cloud connectors (OAuth) | Microsoft-managed tokens | Per-environment | Cloud service integrations | | CyberArk / Azure Key Vault | External vault | Vault-managed HSM | Policy-controlled | Enterprise regulated environments |

Local Credentials (Default)

When you create a credential through Data > Credentials without any premium setup, Power Automate stores it locally using the Windows Data Protection API (DPAPI). This means:

• The credential is encrypted with your Windows user profile key
• It only works on the machine where you created it
• If you export the flow and import it on another machine, the credential reference will exist but contain no actual secret
• Other users on the same machine cannot access it

This is fine for personal automation but causes problems the moment you try to share flows or run them unattended on a different machine.

Environment Credentials (Premium)

With a Power Automate Premium license, you can store credentials in the Power Platform environment (backed by Dataverse). These credentials:

• Are scoped to a specific environment
• Can be shared with other users or service principals
• Work across machines as long as the machine is registered to the same environment
• Support role-based access control

To use environment credentials, you navigate to Data > Credentials in the Power Automate portal (not just the desktop app), create the credential there, and reference it in your desktop flow.

External Vault Integration

For organizations that already use CyberArk or Azure Key Vault, Power Automate can pull credentials at runtime instead of storing them locally. This requires:

1. Setting up the vault connector in your Power Platform environment
2. Creating a credential in Data > Credentials that points to the vault entry
3. Granting the Power Automate service principal access to the vault

Using Credentials in Desktop Flows

Once you have created a credential, you use it in actions that require authentication. The most common pattern is web automation login:

# Power Automate Desktop pseudoflow:

1. Get credential "my-portal-login" from Data > Credentials
   -> Stores Username in %CredentialUsername%
   -> Stores Password in %CredentialPassword%

2. Launch browser -> Navigate to https://portal.example.com/login

3. Populate text field (username input) with %CredentialUsername%

4. Populate text field (password input) with %CredentialPassword%

5. Click "Sign In" button

The key actions are:

• Get credential: Retrieves the username and password into flow variables
• The variables are marked as "sensitive" in the flow designer, meaning they display as •••••••• in the UI and in run logs
• You can also use credentials in "Run PowerShell script" or "Run CMD" actions by passing the variables as parameters

Credential Variables Are Not Truly Encrypted in Memory

While Power Automate marks credential variables as "sensitive" in the UI, they exist as plaintext strings in memory during flow execution. If your flow writes a credential variable to a file, logs it, or passes it to an external script, the secret will be visible in plaintext. The "sensitive" flag only controls display in the designer and run history.

Common Pitfalls

Here are the failure modes we see most often with Data > Credentials:

• Credential not found after machine migration. You built a flow on Machine A, exported it, imported it on Machine B. The credential reference exists in the flow definition, but the actual secret is in Machine A's DPAPI store. The flow fails with "Credential not found" at runtime. Fix: recreate the credential on Machine B with the same name, or switch to environment credentials.

• Flow works interactively but fails unattended. DPAPI credentials are bound to a user profile. If you schedule the flow to run unattended under a service account, that account has a different DPAPI store. The credential does not exist from its perspective. Fix: log in as the service account, open Power Automate Desktop, and create the credential under that user profile.

• Renamed credential breaks multiple flows. Credentials are referenced by name, not by ID. Renaming "old-portal-login" to "portal-login-v2" silently breaks every flow that references the old name. There is no refactoring tool. Fix: search all your flows for the old name before renaming.

• Password rotation requires manual update. Local credentials have no automatic rotation. When a password expires and you update it in the target system, you must also update it in Data > Credentials. If you forget, flows fail the next time they run. Environment credentials with vault integration solve this since the vault handles rotation.

• MFA blocks credential-based login. If the target application enforces multi-factor authentication, a username and password from Data > Credentials will not be enough. The flow will reach the MFA prompt and get stuck. Workarounds include using app passwords (if supported), service accounts with MFA exemptions, or OAuth-based connection references instead of stored credentials.

Data > Credentials vs. Cloud Connection References

Power Automate has two different credential systems, and confusing them is a common source of frustration:

| Feature | Data > Credentials (Desktop) | Connection References (Cloud) | |---|---|---| | Primary use | Desktop flow authentication (web login, DB connect) | Cloud connector authentication (SharePoint, Outlook, SQL) | | Auth method | Username + password stored locally or in Dataverse | OAuth tokens managed by Microsoft | | MFA handling | Cannot handle MFA prompts | MFA handled during initial consent | | Token refresh | No tokens, password stored as-is | Automatic token refresh | | Sharing | Manual (local) or environment-scoped (premium) | Per-environment, delegated consent | | Rotation | Manual unless vault-backed | Automatic via OAuth |

If your automation only needs to call cloud APIs (Microsoft 365, SQL Server, HTTP endpoints with OAuth), use connection references instead of Data > Credentials. Connection references handle token refresh and MFA automatically.

Use Data > Credentials when you need to automate UI-based login (typing a username and password into a web form or desktop application) where OAuth is not available.

How AI Agents Handle Credentials Differently

The traditional RPA approach to credentials, including Power Automate's Data > Credentials, assumes you are automating a fixed login flow: navigate to a page, fill in a form, click submit. This works until the login page changes, MFA gets added, or a CAPTCHA appears.

AI desktop agents take a fundamentally different approach. Instead of storing credentials and replaying them into form fields, they use the operating system's native credential store and browser sessions:

| Approach | How It Works | Resilience | |---|---|---| | RPA (Power Automate) | Store username/password, replay into UI elements by selector | Breaks when selectors change, cannot handle MFA or CAPTCHA | | AI agent (browser session) | Use existing browser sessions where the user is already logged in | Survives UI changes, MFA already completed, session cookies valid | | AI agent (OS keychain) | Read credentials from macOS Keychain or Windows Credential Manager at the OS level | Single source of truth, rotation happens in one place |

The key difference: RPA tools manage their own credential store (Data > Credentials), while AI agents defer to the credential stores that already exist on your machine. This eliminates the synchronization problem where you update a password in one place and forget to update it in another.

Practical Example: Logging Into a Portal

With Power Automate:

1. Store credentials in Data > Credentials
2. Launch browser
3. Navigate to login page
4. Find username field by CSS selector
5. Type stored username
6. Find password field by CSS selector
7. Type stored password
8. Click submit button
9. Hope the selectors have not changed and MFA is not enabled

With an AI desktop agent:

1. Open the portal (your browser already has a valid session cookie)
2. The agent sees you are already logged in and proceeds with the task
3. If the session has expired, the agent uses the OS keychain to authenticate, handling whatever login flow the site presents

No separate credential store to maintain. No selectors to break. No MFA workarounds.

Checklist for Setting Up Credentials in Power Automate

Here is a step-by-step reference for getting Data > Credentials working correctly:

1. Open Power Automate Desktop and edit your flow
2. Navigate to Data > Credentials in the left panel
3. Click "New credential" and give it a descriptive name (e.g., portal-prod-svc-account)
4. Enter the username and password for the target system
5. In your flow, add a "Get credential" action and select the credential by name
6. Use the output variables (%CredentialUsername% and %CredentialPassword%) in subsequent login actions
7. Test the flow interactively first to confirm the credential works
8. If running unattended, ensure the credential exists under the service account's profile
9. For team sharing, upgrade to environment credentials in the Power Platform portal
10. For regulated environments, configure vault integration (CyberArk or Azure Key Vault)

Wrapping Up

The Data > Credentials feature in Power Automate is the built-in way to store and reuse login secrets in desktop flows. It works well for simple cases on a single machine, but quickly hits limits around sharing, machine migration, MFA, and password rotation. For production deployments, environment credentials or vault integration are worth the premium license cost. And if you are evaluating automation approaches beyond RPA, AI agents that leverage existing browser sessions and OS-level credential stores avoid the entire category of credential synchronization problems.

Fazm is an open source macOS AI agent that uses your existing browser sessions and macOS Keychain instead of a separate credential store. Open source on GitHub.