Skip to Content
GuidesOrchestration Automation

Building Orchestration Automations

This guide walks through designing and deploying a multi-step, multi-channel orchestration in Zeotap. By the end you’ll have an automated flow that moves members through a sequence of steps based on timing and their data, with branching and exit criteria.

When to use an orchestration

Reach for an orchestration when you need to:

  • Run a sequence of sends across channels (email, SMS, push) based on timing and conditions
  • Route members down different paths by their attributes or behavior
  • Coordinate multi-day flows like onboarding, re-engagement, or renewal reminders

If you only need a one-time push of an audience to a destination, use an audience sync instead. Orchestrations are for multi-step, time-based flows.

Prerequisites

  • A Zeotap workspace with permission to manage orchestrations
  • A parent model, and an audience on it (or an event model related to it) to serve as the entry
  • At least one connected destination for your sends

Design your flow first

Sketch the member experience before building. Two common shapes:

Welcome series

  1. Entry — new signups
  2. Delay — 1 hour
  3. Send — welcome email
  4. Delay — 3 days
  5. Branch — completed onboarding?
    • Yes — Send tips & tricks email, then Exit
    • Catch-all — Send reminder email, Delay 2 days, then Branch on onboarding again (Exit if done, otherwise send a final nudge and Exit)

Re-engagement

  1. Entry — inactive 30+ days
  2. Send — “we miss you” email
  3. Hold Until — made a purchase, timeout 5 days
    • Condition met — Send thank-you, then Exit
    • Timed out — Send final offer, then Exit

Step 1: Create the entry audience or event

The Entry tile draws from either an audience or an event on the parent model.

For an audience entry, build an audience that captures members at the right moment. Use a narrow window so members enter when relevant — an audience of “everyone who ever signed up” would admit everyone at once.

For an event entry, make sure the event model is related to the parent model.

Step 2: Create the orchestration and configure Entry

  1. Navigate to Orchestrations in the left sidebar and click Create Orchestration.
  2. Name it and choose the parent model.
  3. Click the Entry tile and set the entry type:
    • Audience — pick the entry audience.
    • Event — pick the event model and its relationship, and optionally an event property filter.
  4. Enable Allow re-entry if members should be able to run through again after exiting.
  5. Set the schedule — how often the orchestration checks for new entrants and advances members.

Step 3: Add delays and branches

Drag tiles from the Add Tile palette and connect them.

Delay and Hold Until

  • Delay waits a fixed duration (hours or days) before advancing — for example, 1 hour before the first message, then 2–5 days between messages.
  • Hold Until waits for a condition to become true, up to a timeout — for example, hold until the member makes a purchase, timing out after 5 days. It’s the tile to use when the next step depends on a member action rather than a fixed wait.

Branch and A/B Split

  • Branch routes members by filter conditions. Add one branch per path, each with a filter, and remember there is no automatic else — add a catch-all branch (empty filter) last for members who match nothing.
  • A/B Split routes members by percentage. Use it to test message variants — for example, 50% Variant A, 50% Variant B — keeping a holdout for comparison.

See Branching for the full detail on both.

Step 4: Configure destination sends

A Send to Destination tile pushes members to a connected destination.

  1. Drag a Send to Destination tile and connect it.
  2. Choose the destination.
  3. Define the field mappings — map the parent model’s columns and traits to the destination’s fields. Personalization comes from these mappings; for messaging destinations, the specific message or template is selected through the destination’s own target settings.
  4. If you need a per-tile variation (for example, a different template for this step), set a destination target override on the tile — it overrides the destination’s base settings for this tile only.

Multi-channel

Different Send tiles can target different destinations, so a single flow can mix channels:

  • Delay 1 day, then Send email (welcome)
  • Delay 3 days, then Send push (feature highlight)
  • Delay 5 days, then Send SMS (special offer)

Step 5: Set exit criteria

Beyond reaching an Exit tile, define exit criteria so members leave early once they’ve converted or opted out — a filter over the parent model that removes any matching member wherever they are. This prevents sending further steps to members who’ve already acted.

Step 6: Rehearse, activate, and monitor

  1. Click Run Rehearsal to simulate the flow over a time window without sending anything, and confirm members land where you expect.
  2. Click Save, then Activate — the canvas is validated first (one Entry tile, no cycles, required config present).
  3. Once active, watch the live per-tile counts on the canvas and the run history. See Execution & Monitoring.

Iterate

Use the live counts to find where members pile up or drop off:

  • Most members take the catch-all branch — the earlier branches may be too strict, or members need more time; adjust the filter or the preceding Delay.
  • High exit at one send — the content may be causing opt-outs; review the message or timing.
  • A/B test — compare the counts reaching each variant’s Exit tile to see which performs better.

To change an active orchestration, Pause, edit, then Resume — members continue from where they were.

More patterns

Post-purchase follow-up

  1. Entry — recent purchasers
  2. Delay 1 day, then Send order confirmation + recommendations
  3. Delay 7 days, then Send “how’s your product?”
  4. Delay 14 days, then Branch — left a review?
    • Yes — Send loyalty reward, then Exit
    • Catch-all — Send review request, then Exit

Renewal reminders

  1. Entry — subscription expiring in 30 days
  2. Send — 30-day reminder
  3. Delay 23 days, then Branch — renewed?
    • Yes — Send confirmation, then Exit
    • Catch-all — Send 7-day reminder, Delay 6 days, then Branch on renewal again (Exit if renewed, otherwise send a final-day email + SMS and Exit)

Event-driven upsell

  1. Entry — free-plan users
  2. Hold Until — “feature limit reached” event, timeout 30 days
    • Condition met — Send upgrade offer, Delay 3 days, then Branch — started trial? (if yes, delay 12 days and send a trial-ending reminder before Exit; otherwise send a case study and Exit)
    • Timed outExit

Troubleshooting

IssueCauseResolution
No members enteringEntry audience empty / event not arriving / schedule hasn’t runCheck the audience or event, and the schedule
Members stuck at a sendDestination errorCheck the destination connection and the run’s send detail
Everyone takes one branchBranch filters too strict or too lenientReview the trait/attribute values and adjust; ensure a catch-all exists
Not processingOrchestration is pausedCheck the status in the header

Next Steps

Last updated on