Desktop flows are part of your estate too — inventorying Power Automate for desktop from Dataverse
The finance team has eighty desktop flows running month-end. None of them are in your flow count, because the API you are counting with cannot see them. They are in Dataverse, and here is how to bring them into the inventory before they surprise a migration.
LogiSam··5 min read
Power Automate has two products under one name. Cloud flows run in Microsoft's service and are listed by the Flow admin API. Desktop flows — robotic process automation built in Power Automate for desktop — are stored as Dataverse records and run on machines. They share a portal, a licence family and a name, and nothing else; an inventory built from the Flow API alone has a desktop-flow count of zero.
Where they are
In each environment that has a Dataverse database, desktop flows are rows in the workflows table with category eq 6. Cloud flows are category eq 5 in the same table, which is convenient: one read gives both, with the same owner, state and modified-on columns. Environments without Dataverse cannot have desktop flows, so the absence there is real rather than a gap.
Reading them
name,statecode,modifiedon,_ownerid_value— the same shape as a cloud flow.clientdataholds the definition, base64-encoded; you need it to count actions or search for a hostname.workflowidis the identifier; there is no Flow API name to reconcile with, because the Flow API never sees them.
How they differ in an inventory
They have no trigger in the cloud sense — they are started by a cloud flow's *Run a flow built with Power Automate for desktop* action, by a schedule on the machine, or by hand. They have no connections; they have machine credentials, which are outside every API. And their owner is often a service account, because the machine runs unattended. Label them clearly as desktop, and do not let a filter for *Manual* or *Automated* triggers silently drop them.
How they behave in a migration
Desktop flows go into a solution as components (type 29, the same as cloud flows) and export with it. What does not export is the machine registration, the machine group and the credentials — those are re-created in the destination. And the migrateFlows operation that converts non-solution cloud flows refuses desktop flows outright; add them to the solution directly.
Sharing them
A desktop flow is shared through Dataverse GrantAccess, not through the Flow API. If your tooling shares cloud flows with the migration lead, check that it does the same for desktop flows, or the lead will be able to open eighty percent of the plan.
Keep reading
"Who owns this flow?" — resolving SYSTEM, team and departed owners in Power Automate
Half the flows in a mature tenant show no owner at all in the Flow API. They are not orphans — they belong to SYSTEM, to a team, or to a person who has left — and each of those needs a different action. Here is where the real owner lives and how to read it.
Sharing a Power App or flow with yourself as an admin — legitimately
Being a Power Platform Administrator lets you list every flow in the tenant. It does not let you open one. Before a migration or an incident, that gap has to be closed — here is how it is done through the admin surfaces, and how to leave an audit trail while doing it.
How to inventory an entire Microsoft 365 tenant's Power Platform estate in an afternoon
Every environment, every Power App, every Power Automate flow, every connection — the estate is all there, spread across four admin APIs that each refuse to describe the whole. Here is how to bring it into one list, and what to do about the parts Microsoft will not tell you.