Workflows — multi-step sequences with waits, branches, and splits

Workflows

A workflow is a multi-step sequence Jordyn runs one step at a time: "when someone books, thank them, wait two days, and if they haven't replied, text them." Where an automation is one trigger and one reaction, a workflow has real structure — several messages over days, waits, if/then branching, A/B splits — and a deterministic engine executes every step exactly as written. Nothing is improvised mid-flow.

Building one: describe, interview, plan card, start

1. Describe it in chat. Say the whole flow in plain words — the trigger, the steps, the timing. Jordyn compiles it into a typed plan and saves it as a draft. Drafts never touch a contact.
2. The interview. Jordyn asks about the genuine forks only — one question at a time, each with a one-line why and a recommended answer ("I'd stop the sequence the moment they reply"). Things with obvious defaults are defaulted silently.
3. The plan card. The finished plan appears as a card in chat, in paragraphs a person can read — who gets enrolled, what happens, in what order.
4. Start it — your click. Nothing runs until you press the card's Start button (or Start on the Rules page). Jordyn cannot activate a workflow herself; no such tool exists, on purpose.

The machinery view

The card's "Show me the machinery" (or the Rules page) opens the step editor: a vertical list of plain-word cards, branches and split arms indented under labels, a typed side panel per step, and a "Tell Jordyn what to change" box on every node for people who'd rather say it than form-fill it. Saving mid-flight is safe and explicit: anyone already moving through the workflow follows the NEW steps from wherever they are.

Each step card also carries a quiet stat line ("sent 41 · 9 replied"), branch and split arms show how many contacts went each way, and the workflow list shows the conversion line ("41 enrolled → 12 finished"). The "What happened" view groups every receipt into plain lines, names failures, and offers a per-contact Retry — plus a "Where is someone?" search that finds any contact's exact position.

Merge fields

Every email, text, webhook payload, and field value personalizes with the same tokens:

• {{first_name}} (with fallback: {{first_name|there}}), {{name}}, {{email}}, {{phone}}, {{company}}
• {{custom.<field>}} — any custom field on the contact, e.g. {{custom.policy type}}
• {{owner.name}}, {{owner.email}}, {{owner.company}}, {{booking_link}}
• {{memory.webhook.<name>}} — a captured webhook answer from earlier in the flow

Missing values fall back gracefully — never a blank "Hi ,".

Webhook round-trips

A "send to another system" step POSTs (or PUTs) a JSON payload you build — simple field rows or raw JSON, with the merge-field picker — to any public https address. Secret headers (API keys) are encrypted at rest the moment you save and never shown again; they decrypt only at send time. Delivery retries up to 3 times with a pause between tries, and an optional if-it-fails path runs instead of stranding the contact when every retry fails.

The other system's answer can be captured into a custom field on the contact — the whole response, or one value picked with a path like $.quote.id. Later steps read it back with {{memory.webhook.<name>}} or branch on it. The Test-fire button on the webhook panel sends one real request rendered with a real contact you pick, and shows the status, the response, and exactly what would be captured — nobody is enrolled and no other step runs.

A/B splits

A split step divides contacts across two or more paths by percentage — "test two subject lines" builds one automatically. Assignment is deterministic: the same contact always lands on the same path, so re-runs can't reshuffle your experiment. The editor shows per-arm traffic and each arm's steps carry their own stats, so you can see which variant actually performed.

Texting steps and quiet hours

SMS steps send through your own connected texting service (ClickSend or similar) — Jordyn's built-in text line is reserved for talking to you, the owner. A workflow with a text step won't save or start without a texting service connected, and it tells you so plainly. Texts also respect a hard quiet-hours rule: never before 8am or after 9pm on the contact's local clock (worked out from their area code), regardless of the workflow's send window.

Good to know

• Enrollment policy controls re-entry: once ever, once per N days, or every time — and nobody is ever in the same workflow twice at once.
• Send windows postpone messages to the window's next opening rather than dropping them; email shares the same daily cap as campaigns.
• Waits can be a duration, a time of day, or "until they reply/book" with a give-up window and its own if-it-never-happens path.
• Failures are never silent: a failed step parks that contact visibly with the error on it and a Retry button; everyone else keeps moving.
• Existing prose automations keep working forever — workflows are the structured runtime beside them, not a replacement.