Publishing + versioning

A flow has two payloads:

• payload — the draft. The canvas reads + writes this. Edits don’t affect live runs.
• publishedPayload — immutable snapshot at last publish. The runtime engine executes from this.

Plus a connectionIndex — pre-built button-id → target-step map, baked at publish time so the runtime can resolve a customer’s tap in O(1) instead of walking the JSONB tree.

How to publish

/dashboard/flows → open the flow → top-right Publish button. The dashboard:

1. Validates structure (every interactive block has wired downstream + a non-empty body / question / etc.)
2. Stamps button ids with s[stepId]- prefix so replies route correctly even after future republishes
3. Builds the connection index
4. Bumps publishedVersion
5. Sets publishedAt = now()

What happens to in-flight runs

Existing FlowState rows continue against the OLD publishedPayload snapshot they were started on. Once a customer’s run completes, their next trigger picks up the new version.

To re-trigger an in-flight customer onto the new version, manually expire their FlowState row from the inbox conversation detail.

Test before publish

Open any conversation → Start flow → pick your draft. The runtime can start a flow from its draft payload too (gated to AGENCY_ADMIN + AGENCY_USER) so you can validate end-to-end on a test number without affecting customers.