Manage workflows

Publishing saves the journey that new qualifying customers follow. Later edits stay in its draft until you publish another version. Existing runs retain the version they started, including its steps and step-owned emails.

You need workspace write permission to publish, stop enrollment, pause, resume, duplicate, delete or terminate a run. Choose the control by the work you intend to stop:

For example, stop new runs when retiring an old reminder while allowing already-enrolled customers to finish. Pause when the current email or external action needs investigation. Terminate affected runs if continuing their original version would be wrong.

Publish it to make it live

The Publish button appears at the top of the editor whenever you have changes that have not been published. maxclicks checks the whole workflow first, then asks you to confirm: publishing applies your changes to all new triggers.

If anything is wrong you get Cannot Publish, and the problems are listed on the canvas and inside the offending steps. The usual ones:

Warnings do not block a publish. The scheduled timestamp is set in the past and Without a data key, next steps will have no access to the found records are worth reading before you go ahead, not after.

You also need something to publish. If nothing has changed since last time, the publish is refused.

Keep editing while it runs

You edit a workflow in place, and steps can sit half finished while you work. None of it touches the live version. Your edits go live only when you publish again, and until then the workflow carries a Draft badge alongside its live status.

Publishing takes a frozen copy of the steps, connections and step-owned email templates, called a version. Later draft edits do not alter that copy. Publishing also replaces the live trigger configuration and resumes a paused workflow. A separate Stop new runs setting remains in place when you publish; publication does not clear it.

• New triggers always start on the newest published version.
• Runs already going finish on the version they started with, however many times you publish in the meantime.
• Every step is checked once more just before it executes, so a step that has become invalid fails that run rather than doing something unintended.

This is why the canvas in the Runs tab can look different from the one you are editing: it shows the workflow as it was when that run began.

Pause it without losing anything

Pausing prevents new runs and parks existing runs before they execute more steps. It does not undo completed writes or recall a request or email already in flight. Use it to contain a problem while you inspect the affected runs.

A Delay keeps its saved deadline while paused. Resuming does not start the wait again; a deadline that has passed can continue once execution resumes. To end a particular journey permanently, use Terminate run in Runs. There is no skip or rewind control.

Existing runs still belong to their original published version. If that version contains a faulty step, publishing a correction does not repair those runs: publication resumes the workflow, including work waiting on older versions. Review that consequence before publishing a fix.

In the editor, a published workflow shows a Live button at the top. Click it, confirm, and it turns into Paused. Click that to resume. You can do the same from the ⋯ menu on the workflows list, with Pause and Resume.

Use the Runs tab to inspect the version and current step before resuming. A pause is an execution hold, not a new version or a replay of every event that occurred during the hold. If Stop new runs is also active, resuming execution keeps new enrollment stopped.

Stop enrollment while customers finish

In the published workflow's editor, click Stop new runs. The control changes to Resume new runs. Existing runs continue using their original versions, so this is useful when replacing a journey or completing its last enrolled cohort.

Stopping enrollment does not recall email or undo records already written. Already accepted trigger work and setup-change entry history are separate durable work to inspect. Check Runs and any setup review status when retiring a workflow; a button click is not evidence that every earlier entry has finished.

Resume new runs re-enables enrollment only when the workflow is also unpaused. Activity from a stopped interval is not a general historical backfill. If you need an initial cohort, review that audience and its enrollment separately.

End an individual journey

Open Runs, select the run and click Terminate run in its details. Confirm the action to end that run, child runs and pending continuations. Other customers' runs and the workflow's enrollment setting are unchanged.

Completed external effects remain: termination cannot recall an accepted email, reverse an HTTP request or restore a deleted record. The history records an explicit termination at the current step, which can make the run count as failed. Inspect accepted effects before arranging replacement work.

A run or child that is committing a step can temporarily block termination. Read the error and retry after that step settles. A very large descendant tree may require terminating child runs first. This is a stopping control, not replay-from-step recovery.

Read the status badges

The Status column on the workflows list carries up to two badges at once.

The list also shows the total number of runs each workflow has had, and you can sort by status or by runs.

The Published badge alone does not show whether Stop new runs is active. Open the workflow and inspect its enrollment control as well as Live / Paused. Draft can appear beside either published status because edits and execution state are separate.

Copy or delete one

Duplicate, in the ⋯ menu, copies the current draft and its step-owned emails into a new unpublished workflow. It does not copy run history. If the original has unpublished edits, those edits are part of the copy; inspect it rather than assuming you copied an older live version.

Use a narrow trigger on a test copy. Publishing two copies with overlapping enrollment can give one customer two journeys. An Incoming Webhook gets a separate URL in the copy.

Deletion also cleans up eligible step-owned template previews and can fail if that cleanup or the configuration changes during the operation. Inspect the reported reason. Do not treat a rejected delete as a successfully retired workflow: check enrollment and execution controls explicitly.

Release a correction deliberately

For a repeat-purchase reminder with a wrong customer lookup:

1. Pause to contain further execution and inspect affected runs, their versions and accepted effects.
2. Correct the draft lookup and test customers who should continue and customers who should exit.
3. Terminate old runs that must not continue on the faulty version. A newly published lookup does not rewrite those runs.
4. Set Stop new runs if you want enrollment to remain closed while reviewing the release.
5. Publish the correction. Publication resumes execution, including surviving runs on older versions.
6. Inspect run history, then resume new enrollment when appropriate.

A successful publication validates the graph and required configuration. It does not prove the customer identity, intended audience or external service behavior. Check a real controlled execution before broad enrollment.

Manage it from your own code

The API can list your workflows, read one, and pause or resume it. It cannot create, edit, publish or delete them, and it never returns the steps, the links between them, or the versions. See the workflows API reference.

To start a run from your own code, see triggering a workflow.

Related

• Create a workflow: build the graph.
• Workflow runs: inspect individual runs.
• Workflow billing: how runs consume credits.