Workflow Test Runs and Results
Use dry runs, timelines, dashboards, and version-aware checks to verify workflow behavior.
Workflow provides two levels of proof: a dry run verifies routing without side effects, and real-run dashboards verify production behavior after publication.
Start a dry run
Open the workflow editor, select Test run, and choose one subscriber.
A dry run:
- Uses an isolated run marked Dry run
- Evaluates trigger-independent graph routing for the selected subscriber
- Evaluates conditions, splits, waits, goals, and exits
- Records email and action steps as skipped
- Does not send email, mutate tags or fields, unsubscribe, call webhooks, or enroll another workflow
- Does not count in production active-run or A/B metrics
Use subscribers whose tags, fields, and revenue represent each important path.
Read the timeline
After starting the test, Lumail opens the run timeline.
The left card identifies the subscriber, run number, workflow version, status, current step, and next action. The trace records:
- Step started and completed
- Condition and split decisions
- Wait scheduling and timeout behavior
- Dry-run email and action skips
- Goal reached
- Exit reason
- Failure details
Click a step in the trace to inspect its events in execution order.
What a dry run cannot prove
A dry run does not prove:
- Email rendering or inbox delivery
- Real webhook responses
- Tag, field, unsubscribe, or cross-workflow side effects
- External success-goal events arriving later
- Queue latency or organization sending limits
Test-render every email separately, then monitor the first real runs after activation.
Workflow dashboard
The dashboard combines the published graph with current production data:
- Total, active, waiting, completed, canceled, and failed runs
- Current subscribers by step
- Recent enrollment trend
- Delivered and opened email totals
- Recent runs
- A/B assignments and success rates
Dashboard counts should always be interpreted with the published version and selected time window in mind.
A/B results
The A/B success results card counts one assignment per run and split step. Success means that run recorded a top-level success goal.
See A/B Testing before comparing rates.
Run statuses
| Status | Meaning |
|---|---|
| Active | Executing or ready for its next step |
| Waiting | Waiting for time, an event, subscriber state, or sending access |
| Completed | Reached the end, a goal, or an explicit Exit step |
| Canceled | Stopped by a global exit rule, group conflict, removal, or lifecycle action |
| Failed | Stopped by an unrecoverable error |
Use the timeline event—not status alone—to distinguish normal completion, goal conversion, and explicit exit.
Production verification checklist
- Confirm the intended version is published and status is active.
- Inspect the first real enrollment.
- Verify its version, first route decision, and next action time.
- Confirm workflow email render, sender, and unsubscribe link.
- Confirm each external side effect by read-back.
- Inspect goal or exit events when expected.
- Check failures and runs waiting longer than their configured timeout.
- For A/B tests, confirm both assignment counts increase before interpreting rates.
Troubleshooting
| Symptom | Check |
|---|---|
| No new runs | Workflow status, published version, trigger filters, repeat cooldown, and group conflicts |
| Run stuck waiting | Next action time, timeout route, audience-change flag, and sending suspension |
| A/B success is always zero | A top-level success goal exists and can match real events |
| Unexpected exit | Matched rule and version in the timeline |
| Dry run skipped an email | Expected behavior; render or send a dedicated email test instead |
| Real run uses old logic | It enrolled on an older immutable version |