Branching and supporting spinners
Not every contact should follow the same path. CXGear gives you two complementary tools:
- Decision branches inside one spinner — “if this, go left; otherwise go right”
- Supporting (child) spinners — separate published pipelines that start from a parent when a condition is met (retries, callbacks)
Use branches for split logic in one run. Use supporting spinners when the follow-up is really a second job (for example “try WhatsApp again tomorrow” or “callback child”).
Decision branches (inside one spinner)
Section titled “Decision branches (inside one spinner)”A decision step evaluates conditions and sends the row to different next steps.
Examples:
- Phone present → WhatsApp; otherwise → log “skipped”
- AI score is hot → human agent call; otherwise → email
- Disposition already set → stop; otherwise → continue outreach
In the spinner builder you add branches with a when condition, a label, and a target step. Keep a default path so rows that match nothing still go somewhere safe (log and stop is better than hanging).
src/assets/screenshots/38-spinner-branches.pngDesign tips for branches
Section titled “Design tips for branches”- Prefer simple conditions operators can explain
- Put expensive AI steps only on the paths that need them
- End each path with a Tag / disposition so Records stays clear
- Publish after changing branch targets
Conditions often refer to metadata or earlier step outputs. Use the field names you configured as metadata — do not invent columns that only exist in the full CSV.
Parent and supporting (child) spinners
Section titled “Parent and supporting (child) spinners”A supporting spinner is a child pipeline linked to a parent. It usually starts automatically when the parent finishes a row with a matching condition (for example disposition equals Retry). You typically do not click Run now on the child.
| Role | What you do |
|---|---|
| Parent | Main outreach or analysis recipe; you run or trigger this |
| Supporting child | Follow-up recipe; linked by condition; published separately |
On the Spinners list, children may show as child / supporting under or beside the parent.
src/assets/screenshots/39-supporting-spinner.pngWhen to use a child instead of a branch
Section titled “When to use a child instead of a branch”| Prefer a branch when… | Prefer a supporting spinner when… |
|---|---|
| Paths run in the same job immediately | Follow-up should be a separate run / job |
| Logic is a simple fork (send A vs B) | Retry or callback policy is its own recipe |
| You want one journey timeline | You want parent and child jobs visible separately |
Classic pattern: parent sends WhatsApp and tags Retry; supporting child runs a second WhatsApp attempt when that disposition appears.
In the builder you may see Add supporting spinner when designing parent/child links. Publish both sides after edits.
Plan limits note
Section titled “Plan limits note”Main (non-supporting) spinners count toward your plan’s spinner cap. Supporting children are excluded from that count so retry designs do not burn seats in the spinner meter — but jobs and records they process still count monthly. See Plan limits.
Success looks like
Section titled “Success looks like”- Rows take the correct branch (check journey messages)
- Default path handles odd data without silent drops
- Child jobs appear when parent conditions match
- Operators run the parent only; children start on their own
Common problems
Section titled “Common problems”| Symptom | Likely cause | What to do |
|---|---|---|
| Every row takes the default branch | Condition never matches | Fix field names and values; test with Log |
| Child never starts | Child not published or link condition wrong | Publish child; align disposition / condition text |
| Ran the child with Run now | Supporting spinner is not the entry point | Run the parent instead |
| Old branch behavior | Forgot to republish | Publish parent (and child) |
| Too many main spinners | Duplicated parents instead of children | Consolidate; use supporting links |