Tile Types
The orchestration canvas uses eight tile types to define the steps members move through. Each tile has a specific purpose, configuration options, and connection rules.
You add tiles from the Add Tile palette on the left of the canvas — drag a tile onto the canvas, or click it to add at a default position.
| Tile | Purpose |
|---|---|
| Entry | Define who enters the orchestration |
| Send to Destination | Sync members to a configured destination |
| Branch | Route members down different paths by filter conditions |
| A/B Split | Split members across paths by percentage |
| Delay | Wait a fixed duration before the next step |
| Hold Until | Wait until a condition is met or a timeout is reached |
| Memory | Store a key/value on each member’s context |
| Exit | Remove the member from the orchestration |
Entry
The Entry tile defines how members enter the orchestration. Every orchestration has exactly one Entry tile, and it is the starting point of the canvas (no incoming connections).
Configuration
| Field | Type | Required | Description |
|---|---|---|---|
| Entry Type | Select | Yes | How members enter: Audience or Event |
| Audience | Select | Conditional | The audience whose members enter (for audience entry) |
| Event Model | Select | Conditional | The event model that triggers entry (for event entry) |
| Relationship | Select | Conditional | The relationship linking the parent model to the event model (for event entry) |
| Event Property Filter | Filter | No | Optional property conditions on the triggering event |
| Allow re-entry | Toggle | No | Whether a member who has exited can enter again |
Entry Types
Audience Entry
Members of the selected audience enter the orchestration. Only audiences built on the orchestration’s parent model are selectable.
Membership is re-evaluated on each scheduled evaluation, so members who newly qualify for the audience enter on the next run.
Event Entry
Members enter when a specific event occurs. Select an Event Model (a model whose entity type is event), and Zeotap resolves the relationship from the orchestration’s parent model to that event model:
- If exactly one relationship exists, it is selected automatically.
- If several exist, choose the correct one from the dropdown.
- If none exist, create a relationship between the parent model and the event model first.
Once the event model and relationship are set, you can add an optional Event Property Filter — only events matching those property conditions trigger entry (for example, cart_value > 50).
Manual entry is not supported. Members enter only through an audience or an event.
Re-entry
By default a member enters an orchestration once. Enable Allow re-entry on the Entry tile to let a member who has exited enter again when they re-qualify.
Connection Rules
- No incoming connections.
- One outgoing connection (to the first step).
Send to Destination
The Send to Destination tile syncs matched members to a configured destination — this is how orchestrations activate data, pushing members to email platforms, ad networks, CRMs, warehouses, and more.
Configuration
| Field | Type | Required | Description |
|---|---|---|---|
| Destination | Select | Yes | The destination to send members to |
| Audience ID | Text | No | Optionally override which audience is synced to the destination |
| Field mappings | Mapping | Yes | Map source columns and traits to the destination’s fields |
| Destination target overrides | Fields | No | Optionally override the destination’s target settings for this tile |
Field Mapping
Map member data to the fields the destination expects. Sources you can map from include:
- Model columns — attributes from the orchestration’s parent model (for example,
email,first_name) - Traits — computed attributes on the parent model (for example,
lifetime_value)
The field-mapping editor supports the same type casts, PII hashing, and transforms as audience syncs. Where the parent model’s column configuration marks a field as PII, values are hashed on send.
Destination Target Overrides
A destination has base target settings (for example, a list ID or a message template). The Destination target overrides let you override those settings for this specific tile — for example, a different SendGrid template ID for this orchestration — while leaving the base destination unchanged. Fields left blank inherit the destination’s base configuration.
Connection Rules
- One incoming connection.
- One outgoing connection.
Branch
The Branch tile routes members down different paths based on filter conditions. See Branching for a deeper walkthrough.
Configuration
| Field | Type | Required | Description |
|---|---|---|---|
| Branches | List | Yes | One or more branches, each with a port name, a label, and a filter |
Each branch has:
- Port name — the identifier the outgoing edge connects to (for example,
branch_0) - Label — a readable name for the path (for example, “High value”)
- Filter — the condition a member must match to take this branch
How Branches Are Evaluated
Branches are evaluated top-to-bottom. Each member takes the first branch whose filter matches, then follows that branch’s outgoing edge.
There is no automatic “else” path. A member who matches no branch is not routed anywhere and stays at the tile. To route the remainder, add a final catch-all branch whose filter matches everyone (an empty filter) and connect it to the path those members should take.
Example (evaluated in order):
- Branch 1 —
lifetime_value > 500→ VIP path - Branch 2 —
lifetime_value > 100→ standard path - Branch 3 (catch-all, empty filter) → nurture path
Connection Rules
- One incoming connection.
- One outgoing connection per branch port (at least two branches to be meaningful).
A/B Split
The A/B Split tile divides members across paths by percentage. Use it for A/B tests and holdout groups.
Configuration
| Field | Type | Required | Description |
|---|---|---|---|
| Branches | List | Yes | Two or more branches, each with a label and a percentage |
- Each branch has a Label (for example, “Variant A”) and a Percentage.
- Percentages must sum to 100%. The panel shows a running total and flags it when it does not equal 100.
- Use Even split to distribute percentages equally across the branches.
How the Split Works
Assignment is deterministic per member and orchestration: the same member always lands in the same branch of the same A/B Split, so re-evaluations and re-entries are consistent. The split is based on a hash of the member and orchestration, not a random draw at evaluation time.
If the percentages sum to less than 100%, members in the unallocated remainder are not routed — always keep the total at 100%.
Connection Rules
- One incoming connection.
- One outgoing connection per branch.
Delay
The Delay tile pauses each member at that point for a fixed duration before advancing.
Configuration
| Field | Type | Required | Description |
|---|---|---|---|
| Delay Duration | Number | Yes | The amount of time to wait |
| Unit | Select | Yes | Hours or Days |
Behavior
A member waits at least the configured duration, then advances on the first evaluation after the delay expires. Because members move on scheduled evaluations, the exact advance time depends on the orchestration’s evaluation schedule (for example, an hourly schedule resolves delays to the hour).
Examples:
- Wait 1 hour after cart abandonment before the first reminder.
- Wait 3 days after a welcome email before checking engagement.
Connection Rules
- One incoming connection.
- One outgoing connection.
Hold Until
The Hold Until tile holds each member until a condition becomes true, or until a timeout is reached — whichever comes first.
Configuration
| Field | Type | Required | Description |
|---|---|---|---|
| Hold Condition | Filter | Yes | The filter a member must match to advance |
| Timeout | Number | Yes | Maximum time to hold before releasing the member |
| Unit | Select | Yes | Hours or Days |
Behavior
The Hold Condition is checked on each evaluation cycle. When it becomes true, the member advances. If the condition is not met within the Timeout, the member is released from the hold and advances anyway.
Use Hold Until to wait for a member action or trait change — for example, hold until email_opened = true, timing out after 3 days.
Connection Rules
- One incoming connection.
- One outgoing connection.
Memory
The Memory tile stores a single key/value pair on each member’s orchestration context as they pass through it. Stored values persist for the member’s run and can be referenced by later tiles.
Configuration
| Field | Type | Required | Description |
|---|---|---|---|
| Key | Text | Yes | The context key to set (for example, user_segment) |
| Value | Text | Yes | The value to assign to the key (for example, high_value) |
Behavior
Each Memory tile stores one key. To remember multiple values, chain several Memory tiles — each merges its key into the same per-member context, so keys accumulate rather than overwrite.
Connection Rules
- One incoming connection.
- One outgoing connection.
Exit
The Exit tile removes the member from the orchestration. Every orchestration has at least one Exit tile.
Behavior
When a member reaches an Exit tile they are removed from the orchestration’s active members and recorded as exited. If re-entry is enabled on the Entry tile, an exited member can enter again when they re-qualify.
Multiple Exit tiles are common in branched orchestrations — each path can end in its own Exit tile, which makes the per-tile exit counts easy to read in monitoring.
Connection Rules
- One or more incoming connections.
- No outgoing connections.