Stop running Power Automate Desktop flows with a shared user account

Did you know that using a single shared account to run all your Power Automate Desktop flows is one of the most common — and most dangerous — patterns in enterprise RPA?

I see this constantly with clients. One account, one password, shared across Dev and Prod, running every desktop flow in the organization. When that password expires, everything stops. When someone leaves the team, nobody knows the credentials. When something fails at 3 AM, there’s no audit trail to tell you who triggered what.

This isn’t just bad practice — it’s a single point of failure wrapped in a security risk.

Why a single shared account is a problem

• Password rotation breaks everything. When the password expires or gets changed, every desktop flow that depends on it fails simultaneously. Recovery means updating credentials across multiple connections, machines, and environments — manually.
• No audit trail. If every flow runs under the same account, Dataverse logs show the same identity for everything. You can’t trace failures, you can’t attribute actions, and you can’t investigate incidents properly.
• Security exposure. That shared account typically has broad permissions because “it needs to access everything.” One compromised credential exposes your entire automation estate.
• Environment bleed. Using the same account in Dev and Prod means a misconfigured test flow can accidentally run against production data.

The four identities you actually need

Separation of responsibilities is by design in Power Automate. There are four distinct roles in any enterprise PAD setup, and each one should map to a dedicated account. Using a single user for all of them works — but it’s not recommended, and it creates the exact problems described above.

1. Machine Registration — who registers and manages machines

This account installs the Power Automate Machine Runtime, registers machines or machine groups in the environment, and manages their lifecycle.

• Recommended account: IT Admin or CoE account (nominative)
• Minimum roles: Environment Maker (in Dev) or Desktop Flows Machine Owner (in Test/Prod)
• Naming convention: <env>-rpa-machineowner@contoso.com

This account doesn’t run flows. It manages the infrastructure.

2. Desktop Flow Runtime — who actually executes the bots

This is the account that runs the desktop flows — attended or unattended. It logs into Windows/RDP on the machine and executes the automation actions.

• Recommended account: Technical service account / bot account
• Minimum roles: Desktop Flows Machine User + Run-only (or Owner) on the desktop flow + access to the machine or machine group
• Naming convention: <env>-rpa-bot@contoso.com

This account does not need to register machines. For unattended scenarios, it requires Unattended RPA capacity and RDP permissions on the target machines.

Each account should:

• Have its own Power Automate Premium license (or be covered by a per-flow plan).
• Be registered as a machine connection on the target machines for that environment only.
• Have a strong, unique password managed through your organization’s credential vault (Azure Key Vault, CyberArk, etc.).
• Be excluded from MFA interactive prompts — use conditional access policies that allow sign-in from the registered machines only.

3. Cloud Flow Orchestration — who runs the cloud flows that invoke PAD

This is a critical distinction that many teams miss: the account that runs the cloud flow is NOT necessarily the same identity that executes the desktop flow. The PAD always runs with the account configured in the Desktop Flow connection (point 2 above), regardless of who triggered the cloud flow.

• Recommended account: Cloud automation service account
• Minimum roles: Environment Maker (in Dev) or Owner on the cloud flow (in Test/Prod) + permission to use the Desktop Flow connection
• Naming convention: <env>-rpa-cloud@contoso.com

This account can also be used for deployments and creating connections. In that case, since it holds the primary ownership of the flows, assigning System Administrator can simplify operations — but evaluate whether that level of access is acceptable in your governance model.

What this account does NOT need:

• No Windows/RDP access
• No Desktop Flows Machine Owner role

4. Operations — who monitors and manages runs in Test/Prod

Someone needs to monitor executions in Automation Center, rerun failures, and enable/disable flows. This shouldn’t require the same privileges as the accounts that build or run the automations.

• Recommended account: Operations / Support user or CoE Ops group
• Minimum roles: Power Automate Operator + read access to flow runs (via a custom security role) + run-only on the flows
• Naming convention: <env>-pp-ops@contoso.com or the actual ops user/group

The complete account matrix

Multiply this by environment (Dev, Test, Prod) and you get a clean, auditable separation where no single account compromise can take down your entire automation estate.

Why machine groups matter for resilience

If you hardcode a specific machine in your cloud flow, you lose resilience. If that machine goes offline, the flow fails with no fallback.

Machine groups give you:

• Load balancing — The platform picks an available machine from the group.
• Failover — If one machine is down, another takes the run.
• Scalability — Add machines to the group without changing the flow.

Register the environment-specific bot account (<env>-rpa-bot@...) as a connection on every machine in that group. This way, any machine in the group can execute the flow under the correct identity.

Deploying across environments: the ALM pattern

Desktop flows live inside solutions, just like cloud flows. But moving them between environments requires attention to the things that change per environment:

What travels in the solution

• The desktop flow definition (steps, actions, UI elements)
• The cloud flow orchestrator
• Environment variable definitions

What does NOT travel (and must be configured per environment)

• Machine connections — Each environment uses its own machines and service account.
• Machine group assignments — The machine group in Dev is not the same as in Prod.
• Connection references — The desktop flow connection reference must be rebound to the correct service account after import.
• Environment variable values — URLs, file paths, credentials references that differ per environment.

The deployment checklist

1. Build in Dev using the Dev service account and Dev machine group.
2. Export the solution (managed) from Dev.
3. Import into Test/Prod — during import, map connection references to the environment-specific service account and machine group.
4. Set environment variable values for the target environment.
5. Test the cloud flow trigger end-to-end — don’t just import and assume it works.
6. Verify the run history — confirm the desktop flow ran under the correct service account on the correct machine.

Use environment variables for paths and config

Desktop flows often reference file paths, URLs, or application-specific settings that differ between environments. Use environment variables in your solution so these values are configured per environment without editing the flow:

• PAD_InputFolder → C:\RPA\Input in Dev, D:\Automation\Input in Prod
• PAD_TargetAppURL → https://app-test.contoso.com in Test, https://app.contoso.com in Prod

Quick audit: are you doing this right?

Ask yourself these questions:

• Do you know which account runs each desktop flow in production right now?
• If that account’s password expired today, how many flows would break?
• Can you tell from the logs who triggered a specific desktop flow run last Tuesday?
• If one machine goes offline, do your flows automatically fail over to another?
• When you deploy from Dev to Prod, do you have a documented process for rebinding connections?

If the answer to any of these is “no” or “I’m not sure,” your RPA setup has a resilience gap that will eventually cause an outage.

The bottom line

Power Automate Desktop is powerful, but it inherits the security and operational maturity of how you set it up. One shared account is fast to configure and easy to start with — and that’s exactly why it becomes the default. But the cost of that shortcut compounds over time: outages when passwords rotate, no traceability when things fail, and security exposure across environments.

Separate your accounts. Scope your roles. Use machine groups. Deploy through solutions with environment variables. It’s more setup upfront, but it’s the difference between an automation platform and an automation liability.