The file that does not exist

There is no “.pad” file in Power Automate Desktop

If you searched for a .pad file extension expecting to find your flow saved somewhere on disk, here is the honest answer and the place your flow actually lives.

Matthew Diakonov, Written with AI

Published June 19, 20266 min read

Direct answer, verified 2026-06-19

No. Power Automate Desktop has no “.pad” file format. “PAD” is just the abbreviation for the product name. The flow definition is stored in Microsoft Dataverse, under the v2 schema, as a workflow record plus desktop flow binary objects. Locally, Windows keeps only a run cache under %LOCALAPPDATA%\Microsoft\Power Automate Desktop. The only portable, file-like artifact you can produce is the copy-as-text you get by selecting actions and pressing Ctrl+C, and it is lossy. Source: Microsoft Learn, Power Automate v2 schema.

Why “.pad” feels like it should be a file

Every other automation tool you have touched writes a file. A UiPath project is a folder of .xaml. A shell script is a .sh. A cloud Power Automate flow exports as a package .zip. So when people see the product abbreviated as PAD, the natural next thought is “where is the .pad file?”

There is not one. Power Automate Desktop was built cloud-first. The authoritative copy of your flow is a row in Microsoft Dataverse, not a document on your machine. That single design decision is the root of most of the friction people hit when they try to back up, share, diff, or version a desktop flow.

Where the flow actually lives

Four different things get conflated when people look for the file. Here is each one, where it sits, and whether you can carry it anywhere.

What you mean	Where it is	Portable?
Flow definition (actions, variables, UI elements)	Microsoft Dataverse, v2 schema, as workflow + desktop flow binary objects	No file you can open
Run logs and downloaded cache	C:\Users\<you>\AppData\Local\Microsoft\Power Automate Desktop\Console\Scripts\<FlowId>\Runs\<RunId>	Local only, regenerated each run
Copy-as-text of selected actions	Whatever .txt you paste the clipboard into	Lossy, no round-trip guarantee
A whole flow as a shippable package	A Dataverse solution export (.zip), through ALM	Opaque archive, not a readable flow file

The v2 schema is documented on Microsoft Learn, including the detail that a single desktop flow definition in Dataverse cannot exceed 16,000,000 characters. The local cache and run shortcuts are covered in the run-desktop-flows reference.

What you find if you go looking on disk

Open the local Power Automate Desktop folder and search for anything named with a .pad extension. You will not find one. What you find is a cache tree keyed by flow id and run id.

Windows, looking for a .pad file

The closest thing PAD has to a file, next to a real one

On the left is what you actually get from Power Automate Desktop when you want your logic as text: select the actions, press Ctrl+C, paste into Notepad. On the right is how Mediar’s open-source Terminator SDK stores the same kind of automation, a plain .yml file that lives in a git repo.

Clipboard text vs a workflow file you own

# Select actions in the designer, Ctrl+C, paste into Notepad.
# This pasted text is the closest thing PAD has to a flow "file".
SET CompanyCode TO $'''1000'''
Display.ShowMessageDialog.ShowMessage Message: CompanyCode
  Title: $'''FB01''' Buttons: Display.Buttons.OK
# There is no .pad file on disk that holds this.
# UI elements, element screenshots, and subflow links
# do NOT travel with this clipboard text.

-67% fewer lines

The right-hand file is not an illustration. It is apps/desktop/src-tauri/workflows/comprehensive_ui_test.yml, a 541-line workflow checked into the MIT-licensed github.com/mediar-ai/terminator repository. You can read it, diff it, review it in a pull request, and copy it between machines, because it is a file. That is the thing the .pad search is really looking for.

What Microsoft offers instead of a file

To be fair to Power Automate Desktop: the cloud-first model is not an oversight, it is the point. Dataverse storage is what gives PAD its Application Lifecycle Management story. You put a flow in a solution, export the solution as a .zip, and move it between dev, test, and production environments. For teams living entirely inside Power Platform, that is a coherent workflow.

The catch is that a solution .zip is a packaged archive, not a readable flow. You cannot open it in an editor and see your actions as lines you can review. You cannot run a meaningful git diff across two versions and read what changed. The copy-as-text path gives you readability but drops UI elements, element screenshots, and subflow links, and Microsoft does not promise a clean paste back into the designer. You end up choosing between a portable-but-opaque archive and a readable-but-lossy text dump. Neither is the single-source-of-truth file the question assumes exists.

If your actual goal behind the .pad search is to keep automations in source control, review them like code, and run them on legacy Windows desktop apps without a cloud dependency holding the only authoritative copy, that is the design Mediar starts from. The workflow is the file.

Want your automations to be real, diffable files?

Show us a Power Automate Desktop flow you cannot version or move cleanly, and we will tell you whether a workflow-as-code approach fixes it for your estate. No pitch deck.

The .pad questions, answered

Is there a ".pad" file extension in Power Automate Desktop?

No. There is no .pad file format. "PAD" is just the common abbreviation for the product name, Power Automate Desktop. People type ".pad" expecting a flow file the way a script has a .py or a doc has a .docx, but Power Automate Desktop never writes one. The flow definition lives in Microsoft Dataverse, and locally Windows keeps only a run cache.

Then where is my desktop flow actually stored?

In Microsoft Dataverse, the cloud database behind Power Platform. Under the current v2 schema (Microsoft calls it the Enhanced desktop flow schema, enabled by default since October 1, 2024), the flow is stored as a workflow record plus one or more desktop flow binary objects that hold the actions, images, and metadata. While you edit, the data sits in RAM; on save it uploads to Dataverse; on run it downloads to a local cache and runs from there.

Is there any local file I can find on disk?

Only a cache and run logs, not the editable definition. Run artifacts land under C:\Users\<you>\AppData\Local\Microsoft\Power Automate Desktop\Console\Scripts\<FlowId>\Runs\<RunId>. That folder is regenerated from the cloud copy and is not a portable representation of your flow. Deleting it does not delete the flow, and copying it to another machine does not move the flow.

How do I export or back up a PAD flow as a file, then?

Two honest options, both imperfect. First, select actions in the designer, press Ctrl+C, and paste the textual representation into a plain text file. That captures the action logic but drops UI elements, element screenshots, and subflow references, and Microsoft does not guarantee a clean paste-back. Second, put the flow in a Dataverse solution and export the solution as a .zip through Application Lifecycle Management. That .zip is a shippable package, not a readable flow file you can diff line by line.

Can I put a Power Automate Desktop flow under version control in git?

Not cleanly. There is no canonical text file to commit, so git sees a Dataverse-bound flow as an opaque binary inside a solution export. You can commit the copy-as-text, but it is lossy and there is no enforced round-trip. The Dataverse definition itself is capped at 16,000,000 characters, which is the size ceiling Microsoft documents for a v2-schema desktop flow. This is exactly the friction the .pad searches keep running into.

How does Mediar store an automation differently?

As a plain text file you own. Mediar's open-source Terminator SDK expresses a workflow as a .yml file. A real example in the repo, apps/desktop/src-tauri/workflows/comprehensive_ui_test.yml, is 541 lines of tool_name: execute_sequence with a steps list, checked straight into git under the MIT license. You can diff it, review it in a pull request, branch it, and copy it between machines as a file, because it is a file. There is no cloud database holding the only authoritative copy.

More on the desktop layer and what breaks there