Execution & Monitoring

Once an orchestration is active, Zeotap shows how members move through the canvas and keeps a history of every evaluation run. This page covers rehearsal, live monitoring, the run history, and the operational controls.

How execution works

An active orchestration advances members on its schedule. On each evaluation run the engine:

1. Admits new members that match the Entry tile.
2. Advances members whose Delay has elapsed or whose Hold Until condition is met (or timed out).
3. Routes members through Branch and A/B Split tiles.
4. Executes Send to Destination tiles.
5. Removes members that reach an Exit tile or match the orchestration’s exit criteria.

Because advancement happens on the schedule, delays and holds resolve to that granularity (for example, an hourly schedule resolves to the hour).

Rehearsal

Rehearsal simulates how members would flow through the orchestration over a time window — without sending anything. It’s the safe way to check a flow before activating (and it’s also available on an active orchestration).

1. Click Run Rehearsal.
2. Set a window start and window end for the simulation.
3. Optionally restrict the simulated population with a cohort filter.
4. Run it.

The rehearsal reports, per tile, how many members would have entered and how many would be currently there, plus orchestration-level totals for entered, completed, and exited. Nothing is written to destinations.

Live monitoring

While an orchestration is active, the canvas overlays live counts on each tile:

• N active — members currently at that tile
• N exited — for Exit tiles, members who have left there

At the orchestration level you can see the totals:

Counts reflect the most recent evaluation run, so they update each time the orchestration runs.

Run history

Every evaluation is recorded as a run. The run history table shows each run’s:

• Status — pending, running, completed, or failed
• Timestamps — when the run started and finished
• Member counts — how many members the run processed
• Error information — the reason a run failed, when applicable

A run that is pending or running can be cancelled from the table.

Destination sends

For sends made by Send to Destination tiles, you can drill into the delivery detail:

• Per run — the destination sends produced by a specific run
• Per tile — the destination sends produced by a specific Send to Destination tile

Warehouse tables

Zeotap runs orchestrations directly in your warehouse, and materializes the member state and event log as tables you can query. For each orchestration it creates two tables in a dedicated CDP_JOURNEY schema (in the same warehouse as the orchestration’s parent model). Query them from SQL or your BI tools for custom reporting, to join member state against your own data, or to debug a flow.

Both tables are suffixed with the orchestration’s short ID — the first eight characters of the orchestration’s ID with hyphens removed. For an orchestration 1f2e3d4c-56ab-..., the tables are JOURNEY_MEMBERS_1f2e3d4c and JOURNEY_LOG_1f2e3d4c.

Column data types vary by warehouse: JSON columns are VARIANT on Snowflake, JSON on BigQuery, JSON-encoded STRING on Databricks, and JSON-encoded String on ClickHouse.

Member state — JOURNEY_MEMBERS_<shortid>

One row per member, holding their current position and state in the orchestration.

A member’s status is exited whether they reached an Exit tile or matched the orchestration’s exit criteria. This table is the source of the live per-tile active counts shown on the canvas.

Event log — JOURNEY_LOG_<shortid>

An append-only log of what happened to each member on each evaluation run — the record behind the run history.

Because the log is append-only, it gives you the full path history of every member — useful for funnel analysis, auditing, or tracing why a specific member ended up where they did.

Example — count how many members each run moved through a given tile:

SELECT run_id, COUNT(*) AS advanced
FROM CDP_JOURNEY.JOURNEY_LOG_1f2e3d4c
WHERE tile_id = 'tile-3' AND action = 'advance'
GROUP BY run_id
ORDER BY run_id;

Lifecycle

• The CDP_JOURNEY schema and both tables are created when the orchestration is first activated. Creation is idempotent, so re-activating is safe.
• The tables persist across pause and resume, so member state and history are retained.
• They are removed when the orchestration is deleted.
• Rehearsals run against temporary sandbox tables that are cleaned up afterward — they never write to these live tables.

Operational controls

Pause and resume

• Pause stops processing: no new members enter and active members are held at their current tile. The orchestration status becomes Paused.
• Resume returns a paused orchestration to Active and processing continues from where it left off.

Pausing is the safe way to make changes — pause, edit the canvas, then resume.

Trigger a run manually

Instead of waiting for the next scheduled evaluation, you can trigger a run immediately (via the API) to process entrants and advance members right away.

Troubleshooting

Next Steps

• Tile types reference
• Branching
• Creating an orchestration