# Execution & Publishing (/docs/workflows/execution-and-publishing)

> For the complete documentation index, see [llms.txt](https://docs.tandemcx.ai/llms.txt). Any page on this site can be fetched as Markdown by appending `.md` to its URL.

Building a flow and putting it live are two separate steps. You **validate** a flow while
editing, and **publish** it when it's ready to handle real traffic.

## Testing a flow before you publish

**Test** in the editor runs the saved version you have open, published or not, as a browser
voice call, a run with starting variables, or a first SMS or chat message, and shows its path on
the canvas. See [Test a Workflow](/docs/workflows/test-a-workflow-with-a-browser-call). Without it,
a flow executes only when a real conversation reaches it, so testing means publishing to a number you can call,
or a workflow that isn't in front of customers yet.

The editor also gives you:

- **File → Verify Flow** checks the flow against the rules below without executing
  anything. It is the fastest way to catch an unset initiator or an empty required field.
- **Test** on an **Integration**, **SharpenDB**, or **Invoke Lambda** node sends that one
  node's configured request and shows you the response, so you can confirm a query or an
  endpoint before the flow depends on it. It runs the node on its own, not the flow
  around it.

After a real conversation, **View in Flow** in [Insights → Call
Logs](/docs/workflows/insights-and-reporting#call-logs) replays it on the canvas, step by
step, against the workflow version that actually ran.

## Validation

A flow must be valid before it can be published. The most common requirements:

- An **initiator** node is set (see [Flow Basics](/docs/workflows/flow-basics)).
- Every **required field** on every node is filled.
- Fields required **in combination** are complete — a Play Message node set up for
  text-to-speech needs content, a language, _and_ a voice, even though each of those
  is optional on its own (a node playing an audio file needs none of them).

Fix any validation issues surfaced in the editor, then publish. **File → Verify Flow**
runs the same checks on demand, so you can see what's outstanding before you're ready
to publish.

Publishing re-runs this validation and is refused if anything fails, so a flow can't go
live in a state the editor would have flagged. This applies to publishing through the
API as well as the editor. Warnings don't block a publish — only errors do.

## Publishing

When your flow is ready, **publish** it to make it live.

<Callout type="warn">
    Publishing saves and promotes the current version to production. Active calls routed to the
    workflow begin using the published version immediately.
</Callout>

Because publishing takes effect right away, treat it as a production deploy:
run the flow first, and prefer publishing changes to high-traffic workflows
during a low-traffic window.

## Versions

Each publish creates a new **version**. Opening a workflow from the workflows list
takes you to its published version; use **File → Manage Versions** to view the
version history, open a draft, or roll back to a previous version if a change
causes problems.

Rolling back re-promotes an earlier version to production, so it's the fast way
to undo a bad publish without re-editing the flow. Versioning also gives you a
record of what changed and when.

## Next steps

<Cards>
    <Card
        title="Error Handling"
        href="/docs/workflows/error-handling"
        description="Handle timeouts, no-reply, and unexpected input safely."
    />
    <Card
        title="Best Practices"
        href="/docs/workflows/best-practices"
        description="Keep flows readable and maintainable."
    />
</Cards>