Ship a flow to production

By default, running a flow executes its live draft — the working copy that changes every time anyone hits save. That's exactly what you want while testing, and exactly what you don't want in production, where a builder's mid-day tweak shouldn't quietly change what your integration does. The fix is to publish a version and pin it.

1. 1
   Publish a version

   When the flow is ready to depend on, publish a version and give it a label — 1.0.0, a date, whatever fits. Publishing freezes a snapshot; the draft can keep moving without touching it.

2. 2
   Pin it in your integration

   Tell the run endpoint to use that published version instead of the draft, with the source field:

   { "source": { "kind": "published", "version": "1.0.0" } }

   Now every call runs exactly that snapshot. { "kind": "published" } with no version runs the latest published, which is convenient. Pin an explicit version when you want a change to require a deliberate flip rather than going live the moment someone publishes.

3. 3
   Keep building safely

   Edit the draft as much as you like — production is unaffected because it's pinned to a version, not the draft. Test your changes in the editor's test pane against the draft, with zero risk to what's live.

4. 4
   Roll out a change

   When the next version is ready: publish it (say 1.1.0), point a staging integration at 1.1.0 to verify it in place, then flip production's pinned version from 1.0.0 to 1.1.0. One line changes; the rollout is deliberate.

5. 5
   Roll back instantly

   If a new version misbehaves, re-pin the previous one. Old versions don't disappear when you publish new ones — rolling back is just pointing source.version at the label that worked.