If you build cloud flows inside solutions, two capabilities change how confidently you can work: drafts and version history. Together they let you save unfinished work, publish only when you are ready, and roll back to an earlier version if something goes wrong. This post walks through how the feature works, why it is limited to solution-aware flows, and the practical details that are easy to miss.
When you author a solution-aware cloud flow, you can save the work to Microsoft Dataverse before the flow is finished. You publish it only when you want the changes to take effect at runtime. As the flow evolves, Dataverse builds up a version history that you can open from the version history panel inside the designer.
What drafts and versioning give you
With a solution-aware flow open in the new designer, you can do four things that were not possible before.
- Save a draft of work in progress, even when the flow still has errors.
- Publish the current draft so it runs in production.
- Review version history to see how the flow changed over time.
- Restore an earlier version as a new draft.
Availability: why solution-aware flows only
Drafts and versioning work only for solution-aware cloud flows, and the reason is storage. Dataverse holds the unpublished draft and the full version history. Because solution-aware flows are defined in Dataverse to begin with, they are the only flows that can carry both. A standard non-solution flow has nowhere to keep that information.
A few practical notes follow from this design. You can get a solution-aware flow in three ways: create it directly in a solution, add an existing flow into a solution, or have it created in a solution by default when the relevant environment setting is enabled. If you have a non-solution flow today, adding it into a solution writes its definition into Dataverse so it can start carrying versions. The capabilities live in the new cloud flows designer rather than the classic designer, since that is where Microsoft is investing. The feature set reached all regions on February 7, 2025.
Saving a draft
Saving a draft is straightforward and forgiving. Open the flow in the designer, make your changes, and select Save draft. A confirmation appears in the information bar, and the flow state shows next to the title. The key point is that a draft saves even with errors, so you can stop mid-change and come back later without losing work or being forced to fix everything first.
Publishing a flow
A draft has no effect at runtime. When you are ready for your changes to go live, open the flow, make any final edits, and select Publish. A confirmation appears in the information bar, and the state indicator next to the title switches from Draft to Published. This separation between saving and publishing is the whole point: you control exactly when new logic starts running for real.
Working with version history
Open the flow and select Version history to bring up the version history panel. Versions are grouped by day, with indicators that mark the latest version, the published version, and past published versions, so you can read the timeline of how the flow evolved. Co-owners see the full history, including changes made by any user, not just their own edits.
Retention is worth planning around. Draft records expire after six months, and published records expire after twelve months. Version history is not kept forever, so do not treat it as a permanent archive or a substitute for source control in a mature ALM process.
Restoring a previous version
If a change does not work out, you can roll back. Open the flow, select Version history, choose the version you want, select Restore, and confirm. The restored version becomes the latest draft in the version history. Because it lands as a draft rather than going live, you get a chance to review it before publishing again.
What you can and cannot do today
It helps to set expectations on the current limits of the feature so you design around them rather than fighting them.
| Question | Answer today |
|---|---|
| Can drafts be tested before publishing? | No. Changes must be published and runnable to be tested. |
| Can you add notes or titles to a version? | No. Versions are identified by timestamp. |
| Can versions be compared side by side? | No. You can view them in succession or in separate browser tabs. |
| Can the version history list be filtered? | No, not at this time. |
| Which version is exported in a solution? | Only the last published version. Drafts and history are not exported. |
For the curious, the underlying storage is split across two Dataverse tables. The Workflow table holds a row for the latest published version and a row for the latest draft, and the version history is stored in the Component Version table. Each version has a GUID, although that identifier is not shown on the version history cards.
A known issue worth noting
There is one quirk to be aware of around flow URLs. When a solution cloud flow is first published, the URL contains a workflow unique identifier that changes with each version. If you later open the flow from the My Flows experience, the URL uses the flow identifier and stays stable. If you open it from the Solution Explorer experience, the URL uses the workflow unique identifier and keeps changing. Microsoft has said it plans to provide a static URL from Solution Explorer. Until then, if you need a stable link to reference, open the flow from My Flows.
Why this matters
Drafts and versioning move solution-aware flows closer to how professional software is built. You can save partial work safely, publish on your own schedule, and recover from a bad change without rebuilding from memory. It is not a full source-control system, and the retention limits mean it should complement your ALM pipelines rather than replace them. Used well, though, it removes a lot of the anxiety from editing flows that other people depend on.
Based on Microsoft Learn documentation for drafts and versioning of solution-aware cloud flows. Product details and limits can change over time, so confirm current behavior in the official documentation before relying on it.