Part 9 of our Workflows Unleashed series. This week: why "which version was running when it broke?" should never be an unanswerable question.
You save a flow at 2 PM. It runs at 3 PM and fails. You open the editor at 4 PM, but you've already made another change at 3:30 PM. Now you're looking at the current flow, not the one that failed. You're debugging the wrong version.
This is the most common debugging mistake in automation, and most platforms make it unavoidable. Flomation doesn't.
Every time you save a flow in Flomation, the entire graph — every node, every edge, every configured input value — is stored as an immutable snapshot. Not a diff. Not a change log. The complete state of the flow at that moment.
This happens automatically. There's no "create version" button, no version naming dialog, no "save as copy." Every save is a version. Every version is permanent.
The practical effect: you can always see what a flow looked like at any point in its history. The revision list shows you when each version was created, and you can inspect any past revision to see exactly what it contained.
This is the feature that eliminates the "wrong version" debugging problem.
When a flow executes, the execution record is linked to the specific revision that was running — not the current (latest) revision. When you inspect a past execution, you see the flow as it was when it ran.
Changed a node's configuration after a failure? The execution record still shows the old configuration. Deleted a node? The execution record still shows it. Rewired the graph? The execution record shows the original wiring.
You're always debugging the actual flow that ran, not the flow as it exists now. This sounds obvious, but it requires the platform to store the full graph per revision and link executions to revisions — which most platforms don't do.
Revisions become even more powerful when combined with environments.
A flow can have different active revisions in different environments. The pattern:
If production breaks after a deployment:
The key word is "switch." You're not reverting changes, rebuilding, or redeploying. You're pointing the environment at a different immutable snapshot. The old revision still exists. The new revision still exists. You're just changing which one runs.
When every save is a version and rollback is instant, there's no cost to experimentation. Try a new approach, save it, run it. If it works — great, promote it. If it doesn't — switch back to the last good revision. The failed experiment is still there in the revision history if you want to revisit it later.
Regulated industries need to answer: "What was running in production on this date?" With revision-linked executions, the answer is always available. You can reconstruct exactly what the system did, with exactly what configuration, at any point in history.
Multiple team members can work on the same flow. Each save creates a new revision. The revision list shows who saved what and when. If someone's change breaks something, the previous revision is one click away.
A revision captures everything:
This means the revision isn't just "the flow" in an abstract sense. It's the exact, deployable, executable state of the automation — ready to run the moment an environment points at it.
Next week wraps up the series with a look at everything we've covered and where Flomation goes from here.
www.flomation.co — free to start, no credit card.