Publishing a spinner

Building a spinner is drafting a recipe. Publishing is what makes that recipe official for jobs. Until you publish, runs do not use your latest edits — and after you publish, the definition is frozen as a version so results stay explainable.

What publish does

When you click Publish:

CXGear saves the current steps, branches, and settings as a version
That version is what Run now, schedules, and API triggers execute
The spinner shows as published on the list

Think of publish like “save a snapshot for production.” You can keep editing the draft afterward, but jobs keep using the last published snapshot until you publish again.

Screenshot needed

Spinner builder with Publish action and a published spinner on the list.

Where: Project → Spinners → Edit / list

Save as: src/assets/screenshots/36-spinner-publish.png

Why versions matter

Each publish creates (or advances) a version of the definition. That matters because:

A job that started on version 3 keeps version 3’s steps even if you later publish version 4
You can explain outcomes (“this disposition came from the steps we published Tuesday”)
Partial edits mid-day do not silently change an in-flight understanding of the pipeline

You do not need to manage version numbers by hand for normal work — just remember: what ran is what was published at run time.

Edit, then republish

A common surprise:

Spinner is published and working
You change a log message, AI prompt, or WhatsApp template
You click Run now
Behavior looks unchanged

Cause: the job used the previous published version. Fix: Publish again after your edits, then run.

Stage	What jobs use
Draft edits only	Last published version (if any)
After Publish	The new frozen definition
Mid-job	The version selected when the job started

When to publish

Publish when:

The step order is correct
Metadata field names in templates match the data table
Channel and AI providers are selected
You are ready for operators or triggers to run the spinner

Do not rely on an unpublished draft for production outreach.

Supporting (child) spinners

Child / supporting spinners are also published definitions. Parent conditions start them automatically. Publish both parent and child when you change either side of a retry or callback design. See Branching & supporting spinners.

Success looks like

List shows the spinner as published
Run now is available (for non-supporting spinners)
After an edit + republish, the next job reflects the new steps
Journey messages match the templates you just published

Common problems

Symptom	Likely cause	What to do
Old behavior after edit	Forgot to republish	Publish, then run again
Cannot run	Never published / still draft	Publish first
Plan limit on publish/create	Spinner count on plan	See Plan limits for spinners
Child never starts	Child not published or link condition wrong	Publish child; check parent disposition / branch