Sequences

​

Saving in the sequence editor

​

What Are Sequences?

┌─────────────────┐
│    TRIGGER      │  ← Starts the sequence
│ (Tag or Event)  │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│     ACTION      │  ← Does something
│  (Send Email)   │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│     LOGIC       │  ← Controls flow
│ (Wait 3 days)   │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│     ACTION      │
│ (Send Email #2) │
└─────────────────┘

​

Private Welcome Previews

​

Sequence Components

​

Start from a Saved Audience

​

Triggers

​

Triggering on Several Lists or Tags

curl -X POST "https://api.sequenzy.com/api/v1/sequences" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Welcome",
    "trigger": "contact_added",
    "listIds": ["list_abc123", "list_def456"],
    "goal": "Welcome new subscribers and introduce the product"
  }'

​

Contact-Added Trigger Scope

• Any contact (the default) starts the sequence for every contact that is added, whether or not they join a list. Use this when contacts arrive from an integration such as PostHog, Stripe, or Supabase - those contacts join no list unless you configure list targeting, so this is the only scope that reaches them.
• Any list starts the sequence only once the contact actually joins a list. Use this when list membership, not the contact existing, is what the sequence is about.

​

Segment-Entered Trigger Behavior

• When you activate a sequence, Sequenzy uses the current segment members as a baseline and does not enroll them automatically.
• Only contacts who enter the segment after that baseline are enrolled.
• Segment triggers are evaluated after relevant subscriber data changes. Segments with time-based conditions, such as “not opened in 90 days”, are also rechecked every few minutes.
• You can optionally stop active contacts if they later leave the triggering segment.
• If you edit the segment definition or reactivate the sequence later, Sequenzy creates a new baseline instead of backfilling historical matches.

​

Segment-Exited Trigger Behavior

• When you activate the sequence, the current members become the baseline. Nobody is enrolled at activation, and contacts who left earlier are not enrolled.
• A contact is enrolled when they stop matching the segment’s filters while staying an active contact. Unsubscribing, bouncing, complaining or being deleted does not count as leaving.
• Exits are checked after relevant subscriber data changes, and every few minutes for time-based conditions. A contact who leaves and matches again within seconds, before the check runs, is not enrolled.
• Editing the segment’s filters, editing or deleting a segment it references, or switching the trigger between entered and exited creates a new baseline, so contacts who stop matching because of your edit are not enrolled.
• Bulk changes to the data the segment filters on also count as leaving. Deleting a list, removing a tag from everyone or clearing an attribute the segment uses enrolls every member who stops matching, so pause the sequence first. Historical imports and backfilled events never count as leaving.
• To stop the sequence when the contact comes back, add an entered_segment stop condition for the same segment.

​

Manual Trigger and One-Time Countdowns

• Start on a date: enroll now, or at a moment you pick. The run stays scheduled (visible in the header) and can be cancelled before it starts.
• Keep enrolling people who join later: anyone who joins the chosen list or segment after the run still enters, landing on the step the countdown is at (a Saturday joiner skips the teasers and gets the last-day emails). The sequence stays manual; a background sync re-checks the audience every few minutes and switches itself off after the last moment, or as soon as you change the trigger away from manual. Over the API this is audienceAutoEnroll on the sequence.

​

What does not start a sequence

• Send an event for the thing that happened. This is the better option in almost every case: enrollment is immediate, and the event payload stays available to every email in the run as {{event.*}} merge tags.
• Build a segment on the attribute and use a segment_entered or segment_exited trigger. This works, but membership is recomputed after relevant changes rather than at the moment you write the attribute, so it is a poor fit when timing matters.

​

Actions

​

Where a step’s email comes from

• Blank - AI writes a new email from your brand profile, or start with an empty canvas.
• Template gallery - pick a designed template. It is copied into a new email for this step, and with a description AI rewrites only the copy inside it, keeping the layout, images, and links exactly as designed.
• Your templates - emails you marked as templates on the Emails page (or in the editor header, or with isTemplate through the API, CLI, and MCP). Use one master design across every step: each step gets an independent copy, so editing step 3 never changes step 1 or the master.
• One of your emails - any campaign, sequence, or transactional email. It is copied too, so the original stays untouched.

​

Call Webhook Steps

• Request: choose GET, POST, PUT, PATCH, or DELETE, plus optional headers and a JSON body template. The URL, header values, and body all support merge tags such as {{email}}, {{subscriber.plan}}, and {{event.order_id}} (use {{urlencode.email}} in query strings). In the JSON body, merge tags must sit inside quotes ({"email": "{{email}}"}) so the template is valid JSON as written - values are then escaped for you, and quotes or newlines in the data cannot break the request. A tag in a bare value position ({"amount": {{total}}}) is not accepted; quote it instead. In the builder the step keeps what you typed and shows the problem until you fix it, and the sequence cannot be activated while it is unresolved; over the API, CLI, and MCP the write is rejected outright. If you leave the body empty on a POST-style request, Sequenzy sends a default payload with the subscriber and sequence context. If a merge tag in the URL path has no value for a subscriber, the request is not sent - https://api.example.com/accounts/{{event.account_id}} would otherwise collapse to https://api.example.com/accounts/ and hit the wrong resource - and the step follows your failure behavior instead. Empty query-string tags are sent as-is.
• Save the response: set a result key (for example lookup) and the JSON response is stored for that enrollment. Later email steps can then use merge tags like {{webhooks.lookup.data.status}} or {{webhooks.lookup.status}}. Nested fields and array indexes work: {{webhooks.lookup.data.items.0.title}}. In the email editor, the variable picker (type {{) offers these tags for every webhook step that runs before the email - and once the step has run at least once, it suggests the actual field names seen in recent responses, with sample values. The most recent response also prefills the email preview, so {{webhooks...}} tags render with real data instead of placeholders. If an email uses {{webhooks.KEY...}} or {{ai.KEY...}} but no step before it saves a result under that key, the editor shows a warning above the canvas and in the activation dialog, and the API, CLI, and MCP list it in the activation and simulate warnings. The email still sends, with those tags empty.
• Failure behavior: pick what happens when the endpoint fails or times out (10 seconds) - continue to the next step, exit the sequence, or stop the enrollment with an error. When a failed call is set to continue, {{webhooks.KEY.ok}} is false and {{webhooks.KEY.status}} holds the HTTP status (0 when the request never completed). The response body is still saved, so data merge tags can resolve to whatever the endpoint returned with the error - wrap them in {{#if webhooks.KEY.ok}}...{{/if}} before putting those values in an email. Only a request that never completed, such as a timeout, leaves data empty.
• Seeing what happened: the step’s N completed badge in the builder lists each subscriber with the HTTP status and the host and path that was called, and a failed call that was set to continue or exit is flagged there in red - so a 500 never looks the same as a clean 200. Click that line to open the full response: the status, the endpoint, the error if there was one, and the saved JSON body, which you can copy. A test run shows the same status line for the request it really sent. The query string is left out of the displayed URL, since it can carry merge-tag values. The body is only available when the step has a result key - without one it is never read from the response at all.

​

Call AI Steps

• Prompt: written like a merge-tag template, so {{first_name}}, {{event.reason}}, and even {{webhooks.KEY.data.field}} values from an earlier webhook step resolve per contact before the prompt is sent. When you add a fresh Call AI step, the builder pre-fills a draft prompt, output fields, and context selection from what the sequence already knows - its trigger, the trigger event’s data shape, and the attribute keys your contacts carry. Review the draft, regenerate it, or start blank; the “Draft for me” button reruns the same drafting at any time. You can cancel a draft or rewrite and keep your current text.
• Context: you choose exactly which contact data is shared with the model - the trigger event data, the contact’s recent activity (their last 1-50 events, newest first), specific custom attributes, and their tags. Nothing you do not select is sent. Over the API, CLI, and MCP the same selectors are includeEventProperties, includeRecentEvents with recentEventLimit, includeAttributes, and includeTags.
• Output fields: the model must return the named fields you define (for example churn_reason_line and winback_angle), each a short fragment capped at a maximum length, with an optional fallback. Output is structured only: free-form model text never lands in an email. Give every field a fallback so a rare model failure degrades to your copy instead of a broken email.
• Test: the editor keeps a Test panel beside every section, so you can edit the prompt, output, or contact data and run it again without switching screens. Press Cmd+Enter (Ctrl+Enter on Windows and Linux) anywhere in the editor to run. A run can cover up to three contacts at once, so you see whether the line holds for different people - recent people who went through the sequence are offered first (their stored trigger event data makes the test realistic), or search for any contact. Nothing is sent to them. Earlier runs stay listed under the newest one, marked with what you changed since, and Restore this version puts the prompt, output fields, and contact data back to what an earlier run used. Your last six runs are kept while the editor is open. Tests use the exact same generation path the live sequence uses. A step is usually built before the sequence has ever run, so when the contact has no stored trigger event data the test falls back to the most recent event of that name in your account, and then to the example payload shown in the builder’s Event Payload panel. You can also point the test at any other event your workspace knows, to see how the line reads for that payload. Each result says which of the three sources it used, and you can rerun a real-data test against the example values.
• Tuning: when a tested line is not quite right, choose Not quite right? Tell AI what to change and say what should be different (“never mention the price”, “sound like a friend, not a brand”) and the step’s prompt is rewritten to hold for every future contact. The rewrite is an edit, not a restart: it keeps the merge tags and the rest of your wording, lands in the Prompt section where you can read and adjust it, runs the test again automatically, and is rejected if the feedback would turn the step into an email writer or strip out the per-contact data.
• Failure behavior: by default a failed generation continues with the fallback text. You can instead exit the sequence or stop the enrollment with an error.

​

Discount Codes In Emails

​

Logic Nodes

​

Delay: fixed duration or “wait until a date”

• For a fixed time (default): wait a set number of days, hours, and minutes before continuing.
• Until a date: resume on a date that belongs to each contact. Read it from the trigger event (for example renews_at or booking.startsAt in the event payload) or from a contact attribute (for example dueDate or renewalDate). The value must be an ISO date such as 2027-02-15 or a Unix timestamp.

• Continue to the next step (default): the contact moves on immediately.
• Skip ahead to the next wait: the contact skips every email and action until the next wait, condition or branch, so they only receive what is still ahead of them.
• Exit the sequence: the contact leaves at this step.

​

Delay: “wait until a weekday window”

​

Waiting a few days first

​

Sending at each contact’s local time

​

Delay: “wait until a key date”

• Skip ahead to the next wait (default): the contact skips every step until the next wait, so someone enrolled on Saturday only receives the “last day”, “final hour” and Cyber Monday emails, never the “7 days to go” teaser.
• Send right away: the contact receives the next step immediately.
• Exit the sequence: the contact leaves at this step.

​

Branch: condition split or random split

• Condition split (default): each path carries a condition such as has_tag, in_segment, or link_clicked. Paths are evaluated in order and an else path catches everyone who matches nothing.
• Random split: each path is a weighted variant. When a subscriber reaches the step they are assigned a path by percentage, so nothing about the subscriber is evaluated. This is how you run a concurrent A/B test inside a sequence - for example sending half of your abandoned-cart contacts a discount offer and half a free-shipping offer at the same time, instead of running two duplicate sequences one after another and comparing across different weeks.

sequenzy sequences update seq_123 \
  --branch-json '{"afterNodeId":"node_cart_wait","splitMode":"random","randomPercentages":[50,50],"branches":[{"id":"discount","label":"10% off","steps":[{"subject":"Here is 10% off","html":"<p>Complete your order.</p>"}]},{"id":"bonus","label":"Free shipping","steps":[{"subject":"Free shipping on us","html":"<p>Complete your order.</p>"}]}]}' \
  --confirm-structural-change

​

Sending Windows

​

Realigning contacts after you change the window

sequenzy sequences realign-enrollments seq_abc123
sequenzy sequences realign-enrollments seq_abc123 --apply
sequenzy sequences realign-enrollments seq_abc123 --job-id <printed-job-id>

​

Frequency Cap

​

BCC Copies

​

File Attachments

[
  {
    "filename": "file-{{event.order_id}}.pdf",
    "path": "{{event.file_url}}"
  }
]

​

Building Sequences

​

The Visual Editor

1. Add a trigger - How does the sequence start?
2. Add actions - What should happen?
3. Add logic - When and how should it happen?
4. Connect nodes - Define the flow between steps
5. Activate - Turn on the sequence

​

Editor Shortcuts and Tools

• Undo / redo - Cmd+Z undoes any unsaved canvas edit (add, edit, delete, reorder, and even Discard changes); Cmd+Shift+Z redoes it. History clears once changes are saved.
• Step finder - Cmd+F opens a search across every step by name or subject and jumps the canvas to the selected one.
• Arrow navigation - Arrow keys walk between steps (left/right move across branch paths). Enter opens the focused email step, Delete removes the focused step, Escape clears the focus.
• Duplicate step - Every action and delay step has a Duplicate button in its editor. Duplicating an email step also clones the email itself, so you can save the sequence and then edit the copy without touching the original.
• Collapse branches - Wide branch sections collapse into a compact summary card (hover the branch step for the toggle). The hidden steps stay part of the sequence; this only tidies up the canvas.
• View toggles - M toggles per-step metrics, F toggles the funnel view, G opens goals, T opens a test run, and Comma opens settings.

​

Deleting Steps While People Are In Them

​

Simulate A Subscriber’s Path

​

Funnel View

• Entry volume - one chip at the top shows how many subscribers ever entered the sequence.
• Losses - a connection only gets a chip when subscribers were actually lost between the two steps, shown as -N with the continuation percentage. Hover the chip for the breakdown: how many failed, stopped early (stop condition or manual removal), or finished the sequence there. Subscribers still waiting in a delay are not counted as lost.
• Branch splits - fan-out connections show how traffic distributes across the paths.
• Engagement decay - each email step shows its open-rate change versus the previous email (for example opens -4.2pts vs prev). In a linear sequence almost everyone reaches the next step, so this is usually the real drop-off signal: it tells you which email to rewrite.

​

Create From A Dashboard Prompt

• Try prompts like Create a welcome sequence or Build a re-engagement sequence
• During onboarding, the assistant also suggests starter questions like What do I start with? and How can I add more about my company?
• You can also ask review questions like Show my top performing sequence to jump from a performance check into the sequence itself
• If Sequenzy recognizes the intent, it opens a matching starter template in the builder
• If your request is more custom, Sequenzy creates a blank draft sequence and takes you straight into editing
• If you keep the conversation going, the assistant opens a follow-up chat so you can ask for more detail without repeating the earlier request

​

Run A Live Sequence Test

• The run starts from the sequence trigger and follows connected steps in order
• Branches, conditions, event-property merge tags, discounts, tags, lists, subscriber attributes, and webhooks use the selected subscriber’s real data
• Delay and wait steps are compressed with the selected speed multiplier, such as 60x, 120x, 240x, or 480x
• Sequence emails are sent through the test-email path with a [TEST] subject prefix
• Recent test runs show step-by-step logs, accelerated wait timing, sent-email references, and failures

1. Save any pending changes in the builder.
2. Choose one existing active subscriber. Direct email recipients are not available for live sequence tests because the run needs subscriber state.
3. Pick a speed multiplier. 120x turns a 1-hour wait into about 30 seconds.
4. Confirm the run. Sequenzy prevents another queued or running test for the same sequence and subscriber.

​

Restrict A Live Trigger To An Allowlist

1. Tag the contacts you want to receive the sequence, for example allowlist.
2. Set the sequence stop condition to does_not_have_tag with value allowlist.
3. Activate the sequence and fire the real trigger.

sequenzy sequences update seq_123 \
  --stop-condition-json '{"type":"does_not_have_tag","value":"allowlist"}'

​

Stop On A Later Event With Property Filters

sequenzy sequences update seq_123 \
  --stop-condition-json '{
    "type": "event_received",
    "value": "product.credit_consumed",
    "matchConfig": {
      "mode": "event_property_filter",
      "propertyFilters": [
        { "path": "quota_used", "operator": "greater_than", "value": 1 }
      ]
    }
  }'

• event_property (for event_received with an event-based trigger): stop only when the stop event’s field equals the same field captured on the enrolling event, for example the same orderId: {"mode":"event_property","rules":[{"entryFieldPath":"orderId","eventFieldPath":"orderId"}]}
• field_value (for field_changed): stop only when the field changes to a matching value: {"mode":"field_value","operator":"equals","value":"pro"}
• entry_audience (for tag/list defaults): use the tag or list recorded when each contact enrolled. Public responses use value: null with {"mode":"entry_audience","audience":"tag"} (or list). This is the same representation stored by the sequence. Tag entry matching requires a tag_added trigger; list entry matching requires a contact_added trigger scoped to at least one specific list.

​

When A Stop Condition Actually Cancels

1. The stop event arrives. It is recorded, sync rules apply, and any sequence triggered by it enrols - but the waiting enrollment is untouched.
2. The enrollment keeps reporting waiting for the rest of the delay.
3. When the delay expires and the enrollment wakes, the stop condition is checked before the next step runs, and the enrollment is cancelled. Nothing sends.

sequenzy sequences enrollments seq_123 \
  --subscriber-id sub_123 --stop-condition-match

sequenzy sequences cancel-enrollments seq_123 --subscriber-id sub_123 --apply

• A sequence has exactly one stop condition. A stop event with any other name never applies, however plausible it looks. The enrollment listing echoes the configured one.
• Only events received after enrollment count. Backdated events (more than an hour in the past) are recorded as history and never satisfy a stop.
• A matchConfig adds payload requirements. With event_property or event_property_filter, the stop event must carry the matching fields, not just the right name. Duplicating a sequence copies its matchConfig too, so a test copy inherits whatever the live sequence required.

​

Example: Welcome Sequence

┌─────────────────────┐
│ Trigger: Tag Added  │
│ "new-signup"        │
└──────────┬──────────┘
           │
           ▼
┌─────────────────────┐
│ Send: Welcome Email │
│ "Getting Started"   │
└──────────┬──────────┘
           │
           ▼
┌─────────────────────┐
│ Delay: 2 days       │
└──────────┬──────────┘
           │
           ▼
┌─────────────────────┐
│ Send: Tips Email    │
│ "5 Pro Tips"        │
└──────────┬──────────┘
           │
           ▼
┌─────────────────────┐
│ Delay: 3 days       │
└──────────┬──────────┘
           │
           ▼
┌─────────────────────┐
│ Send: Feature Email │
│ "Discover Features" │
└─────────────────────┘

​

Example: Post-Purchase Sequence

┌────────────────────────┐
│ Trigger: Event         │
│ "saas.purchase"        │
└───────────┬────────────┘
            │
            ▼
┌────────────────────────┐
│ Send: Thank You Email  │
└───────────┬────────────┘
            │
            ▼
┌────────────────────────┐
│ Delay: 7 days          │
└───────────┬────────────┘
            │
            ▼
┌────────────────────────┐
│ Wait for Event:        │
│ "feature_activated"    │
│ Timeout: 14 days       │
└───────────┬────────────┘
            │
       ┌────┴────┐
       │         │
  Event Fired  Timeout
       │         │
       ▼         ▼
┌───────────┐ ┌───────────┐
│ Add Tag   │ │ Send Help │
│ "engaged" │ │ Email     │
└───────────┘ └───────────┘

​

Emails View

• Change every email. Describe a change, like “make the background cream” or “remove the header”, and the AI makes it in every email. When you ask for a new look (“more premium”, “bolder colors”), the AI designs the first email, then restyles the others in its design, so every email shows once, already matching. Exact changes like “remove the social icons” go to every email at once. The same goes for new text or styles meant for every email, like a footer line or a button color: the AI decides them once and puts exactly the same in each. It can change the footer too, like hiding the social icons or adding a line about who you are; your company name, address and unsubscribe link come from your settings.
• Make them look like one of them. Ask “make them all look like email 1” and every other email takes its style exactly (colors, fonts, headings, buttons), keeping its own words. No AI needed, so it’s instant.
• Try a few designs first. Ask “I like email 1, make a few variations” and design options appear under it. Arrows show which email each option belongs to. Click an option to work on it like an email: ask the AI in the chat, pick a section and use Ask AI under it, or double-click its text to type. Changes to an option are saved with it, and Undo puts it back. Pick one with Use for every email (the others take its style) or Only Email 1, or discard them. You can do the same from the API, the CLI (sequenzy sequences variations) and the MCP tools, where ChatGPT and Claude show the options rendered.
• Change some of them. Name an email (“give email 2 a new structure”), or click one to change only that one. Shift-click (or Cmd/Ctrl-click) to pick several. In a selected email, click a section to change only that section: ask in the chat, or with Ask AI right under the section. Press Delete (or Backspace) to remove the selected sections; Undo brings them back.
• Change a sentence yourself. Click an email, then double-click its text: the canvas zooms in so you can read it. Type, then press Enter (Esc cancels). When your change can’t go into the email exactly as typed, for example because it runs across bold text or a link, the AI makes it for you. Text that is filled in when the email sends, like a subscriber’s name, and the generated footer can only be changed in the editor.
• Emails written in HTML work too: the AI edits their HTML and keeps their own look.
• Review, then save. Changes show on the emails as Unsaved until you save them. Point at Unsaved on an email, or press it on a touch screen, to see the saved version laid over it. Each reply lists what changed in each email, and Undo puts the emails back. Ctrl+Z (Cmd+Z on a Mac) undoes the latest change, asked for or typed, and Shift+Ctrl+Z redoes it. Save writes every changed email; on an active sequence, saved changes go out with the next emails it sends. When the emails you saved have a new look, you can save it as your AI style, so new AI emails start from it. Discard drops them. Unsaved changes stay in this browser if you leave the page.
• Emails sent by more than one step show a link icon. It’s the same email, so a change to it shows in every step that sends it.
• Open one in the editor with the pencil above it, or from the flow, to keep working on it by hand. Unsaved changes to that email are saved first, so the editor shows them.

​

Personalizing Sequence Emails With Event Properties

• {{event.city}}
• {{event.windMaxSpeed}}
• {{event.alert.maxSpeed}}

​

How It Works

• The event snapshot is stored on the automation run when the subscriber enters the sequence
• Every later email in that same sequence reads from the same stored snapshot
• A later event for the same subscriber does not overwrite earlier sequence runs

​

Example

{
  "event": "weather.wind_alert",
  "properties": {
    "city": "Tel Aviv",
    "windMaxSpeed": 75,
    "duration": {
      "hours": 6
    }
  }
}

• Subject: Wind alert for {{event.city}}
• Body: Winds may reach {{event.windMaxSpeed}} km/h for {{event.duration.hours}} hours.

​

Defaults

• {{event.city|your area}}
• {{event.duration.hours|a few}}

​

Using Event Properties in Update Subscriber Steps

• Set a plan attribute to {{event.plan}}
• Set an mrr number attribute to {{event.amount}} (the resolved value is stored as a number)
• Set first name to {{event.firstName}}

{
  "type": "update_subscriber",
  "nodeType": "action_update_attributes",
  "config": {
    "firstName": "{{event.firstName}}",
    "customAttributeUpdates": [
      { "name": "plan", "value": "{{event.plan}}", "valueType": "text" },
      { "name": "mrr", "value": "{{event.amount}}", "valueType": "number" },
      { "name": "active", "value": "{{event.active}}", "valueType": "boolean" }
    ]
  }
}

​

Enrollment Modes

• order.id - one active run per order
• product.providerVariantId - one active run per product variant
• subscription.id - one active run per subscription

{
  "name": "Post-purchase follow-up",
  "trigger": "event_received",
  "eventName": "ecommerce.order_placed",
  "enrollmentMode": "matching_field",
  "enrollmentFieldPath": "order.id",
  "goal": "Follow up about this specific order"
}

​

Unsubscribed and Bounced Contacts

​

Commerce Sequence Stop Behavior

​

Replenishment Due

• provider
• providerProductId
• providerVariantId when the replenishment setting uses variant-level matching
• lineItems[].providerProductId and lineItems[].providerVariantId on later ecommerce.order_placed events

​

Back In Stock

• The subscriber buys the same item
• The same item goes out of stock again

• provider
• providerProductId or product.providerId
• providerVariantId or product.providerVariantId
• lineItems[].providerProductId and lineItems[].providerVariantId on later purchase events
• ecommerce.back_in_stock_out_of_stock events for the same product and variant

​

Condition Types

• If continues only when the condition matches. Otherwise, the subscriber exits the sequence.
• If/Else takes the first matching path, or the Else path if none match.

​

Tag Conditions

Condition: has_tag "customer"
  ├─ Yes → Send upsell email
  └─ No  → Send conversion email

​

List Conditions

Condition: in_list "VIP Customers"
  ├─ Yes → Send exclusive offer
  └─ No  → Send standard offer

​

Segment Conditions

Condition: in_segment "Project invite recipients"
  ├─ Yes → Send project onboarding
  └─ No  → Send standard onboarding

​

Event Conditions

Condition: event_received "project.invite.accepted"
  ├─ Yes → Start accepted-invite flow
  └─ No  → Send reminder

​

Skip contacts who already bought

Trigger: tag_added "trial"
Condition: event_received "saas.purchase" (activityScope: ever)
  ├─ Yes → End
  └─ No  → First email, then the rest of the sequence

{
  "confirmStructuralChange": true,
  "branch": {
    "afterNodeId": "<trigger node id>",
    "branches": [
      {
        "conditionType": "event_received",
        "eventName": "saas.purchase",
        "activityScope": "ever",
        "targetNodeId": "<completion node id>"
      }
    ],
    "elseTargetNodeId": "<first step node id>"
  }
}

​

Clicked Link Conditions

Condition: link_clicked "project-invites"
  ├─ Yes → Start project setup flow
  └─ No  → Send invite reminder

​

Field Conditions

Condition: field_equals "plan" "enterprise"
  ├─ Yes → Assign to sales team
  └─ No  → Send self-serve resources

​

Available Operators

​

Wait for Event

​

What you can wait for

​

Timeout behavior

┌──────────────────────┐
│ Wait for Event:      │
│ "demo_scheduled"     │
│ Timeout: 5 days      │
│ On timeout: continue │
└──────────┬───────────┘
           │  event received OR timed out
           ▼
┌──────────────────────┐
│ Condition:           │
│ event_received       │
│ "demo_scheduled"     │
└──────────┬───────────┘
      ┌────┴────┐
     Yes        No
      │         │
      ▼         ▼
┌──────────┐ ┌──────────┐
│ Send     │ │ Send     │
│ Prep     │ │ Follow   │
│ Email    │ │ Up Email │
└──────────┘ └──────────┘

​

Branching

​

Simple Condition (2 paths)

┌─────────────────────┐
│ Condition:          │
│ has_tag "customer"  │
└──────────┬──────────┘
           │
      ┌────┴────┐
      │         │
     Yes        No
      │         │
      ▼         ▼
┌──────────┐ ┌──────────┐
│ Upsell   │ │ Convert  │
│ Email    │ │ Email    │
└──────────┘ └──────────┘

​

Multi-Branch (3+ paths)

┌─────────────────────────────┐
│ Branch:                     │
│ ├─ plan = "enterprise"      │
│ ├─ plan = "pro"             │
│ └─ else (default)           │
└─────────────┬───────────────┘
              │
     ┌────────┼────────┐
     │        │        │
 Enterprise  Pro    Default
     │        │        │
     ▼        ▼        ▼
┌────────┐ ┌────────┐ ┌────────┐
│ VIP    │ │ Pro    │ │ Basic  │
│ Email  │ │ Email  │ │ Email  │
└────────┘ └────────┘ └────────┘

​

Empty paths

​

Sequence States

​

Pausing One Contact

• In the sequence editor, open Subscribers, then In Progress, and use the pause button on a contact’s row. The same button resumes them.
• From code, use pause subscribers and resume subscribers, the CLI commands sequenzy sequences pause-subscribers and sequenzy sequences resume-subscribers, or the MCP tools pause_sequence_subscribers and resume_sequence_subscribers.

​

Sending Paused

​

Tokens (Subscriber Journeys)

{
  "subscriberId": "sub_abc123",
  "automationId": "auto_xyz",
  "currentNode": "node_456",
  "status": "active",
  "context": {
    "entryPoint": "tag_added",
    "emailsSent": 2,
    "waitingFor": "email_opened"
  }
}

​

Token States

​

Real-World Sequence Examples

​

SaaS Trial to Paid

Trigger: Event "saas.trial_started"
    │
    ▼
┌───────────────────┐
│ Send: Trial       │
│ Welcome Email     │
└─────────┬─────────┘
          │
          ▼
┌───────────────────┐
│ Wait: 3 days      │
└─────────┬─────────┘
          │
          ▼
┌───────────────────┐
│ Send: Tips Email  │
│ "Get the Most..." │
└─────────┬─────────┘
          │
          ▼
┌───────────────────┐
│ Wait: 4 days      │
└─────────┬─────────┘
          │
          ▼
┌───────────────────────┐
│ Condition: has_tag    │
│ "customer"            │
└───────────┬───────────┘
            │
       ┌────┴────┐
       │         │
      Yes        No
       │         │
       ▼         ▼
   (End)    ┌───────────────┐
            │ Send: Last    │
            │ Chance Email  │
            └───────────────┘

​

E-commerce Abandoned Cart

Trigger: Event "ecommerce.cart_started"
Continue while: Tag "ecommerce.in_cart"
    │
    ▼
┌───────────────────┐
│ Wait: 1 hour      │
└─────────┬─────────┘
          │
          ▼
┌───────────────┐
│ Send: Cart    │
│ Reminder      │
└───────┬───────┘
        │
        ▼
┌───────────────┐
│ Wait: 1 day   │
└───────┬───────┘
        │
        ▼
┌───────────────┐
│ Send: 10% Off │
│ Coupon        │
└───────────────┘

​

Re-engagement Campaign

Trigger: Tag Added "inactive-30d"
    │
    ▼
┌───────────────────┐
│ Send: We Miss You │
└─────────┬─────────┘
          │
          ▼
┌─────────────────────┐
│ Wait for Event:     │
│ "session_started"   │
│ Timeout: 7 days     │
└─────────┬───────────┘
          │
     ┌────┴────┐
     │         │
   Event    Timeout
     │         │
     ▼         ▼
┌──────────┐ ┌──────────┐
│ Remove   │ │ Send     │
│ Tag      │ │ Special  │
│ inactive │ │ Offer    │
└──────────┘ └────┬─────┘
                  │
                  ▼
             ┌──────────┐
             │ Wait     │
             │ 14 days  │
             └────┬─────┘
                  │
                  ▼
             ┌──────────┐
             │ Add Tag  │
             │ "churned"│
             └──────────┘

​

Best Practices

​

1. Start Simple

Trigger → Email → Delay → Email → End

​

2. Use Tags for State

- "onboarding-started" (at trigger)
- "onboarding-complete" (at end)

​

3. Set Reasonable Delays

• Welcome emails: immediate to 30 minutes
• Follow-ups: 2-4 days
• Re-engagement: 1-2 weeks

​

4. Always Have Exit Conditions

Condition: has_tag "customer"
  ├─ Yes → End sequence
  └─ No  → Continue emails

​

5. Personalize with Conditions

Branch on plan:
  ├─ Enterprise → High-touch content
  ├─ Pro → Feature-focused content
  └─ Free → Conversion content

​

Test with event properties

​

Reuse received event data for sequence tests

​

Related