What it does
Every Dataverse environment is provisioned with a set of special system users and application users that Microsoft services use to do their work. Power Automate has its own cluster of them, covering AI flows, desktop flow runs, machine management and hosted machine provisioning. They're the accounts you'll see in the Users table that nobody on your team created.
Key facts
- System users cover Microsoft support access and the delegated admin account. Application users are service identities for specific features, each with a system-managed security role.
- Most are hidden from normal views but turn up in Advanced Find on the Users table. They can't sign in, have no mailbox, and don't consume service licences.
- Microsoft's guidance is blunt: don't delete them, don't modify them, and don't change or reassign their security roles. The roles are managed by the system and may not be editable anyway.
- The Power Automate set includes accounts for Desktop Flow AI, AI flows (web and worker), desktop flow runtime, machine management relay and machine provisioning, plus a Flow-RP account and a process mining account. The machine provisioning account holds System Administrator, because it performs database operations while hosted machines are provisioned.
- Records created or updated by these accounts are audited, which is why they show up in audit logs and confuse people.
When to use / skip
This is a reference page, not a feature. Read it when a security review, an audit export or a licence clean-up turns up unfamiliar users in a production environment, and before anyone writes a "remove unused accounts" script.
Configuration decisions
- Whether your user hygiene and access review processes explicitly exclude application users that Microsoft provisions, so they aren't flagged as orphans every quarter.
- Whether your own service accounts are created as separate application users, rather than reusing a built-in one. See the service principals doc for that pattern.
- How audit reports label these accounts so reviewers know which entries are platform activity.
Gotchas
- A clean-up that disables or strips roles from "unknown" users can break AI flows, desktop flow runs or hosted machine provisioning. The failure shows up as a feature outage, not an obvious permissions error.
- Some listed accounts use placeholder-looking domains (fabrikam, contoso). They're genuine, so don't treat the domain as proof of something dodgy.
- The list changes as services are added. Page contents were updated in October 2026, so don't rely on a list pasted into an old governance document.
- Application users that Microsoft manages are not a substitute for a service principal you own. Flow ownership and connection sharing belong with your own identity.
Consultant notes
- Put the built-in users in the access review scope notes on day one. Auditors love an unexplained System Administrator account, and it's far easier to have the answer written down.
- In locked-down tenants, check that your Entra and conditional access policies don't catch these identities. They're service identities, and blocking them quietly breaks platform features.
- When you hand over, tell the client's admin team explicitly not to tidy these up. It's a five-minute conversation that prevents a bad Monday.
- Keep your own application users clearly named and documented, so they're never confused with the platform's.
Worth revisiting after any change to Power Automate's AI flows or hosted machine services.