Journey Studio & Runs

Scope

Custom journeys deserve the same caution as any automation that touches live tickets. This guide keeps the authoring and run model and removes private implementation detail.

This manual covers authoring custom journeys in the studio (journeys.manage) and working with journey runs. Enabling and tuning

Authoring a custom journey

Open Journeys → New journey (or Edit on a hand-authored journey). The studio is three panels: basics + trigger, conditions, and the ordered step list, with a live dry-run preview on the right.

• Conditions are picked, not typed. The field dropdown lists every field a condition may test (ticket fields plus the temporal age_hours / days_since_update family), served by the API — you cannot save a condition on a field Beacon doesn’t know. A misspelled field used to silently match every ticket; it is now a save-time error. Choose context.<key>… to test a trigger-supplied context value (chat slots, automation outcomes).

• Step parameters are validated against a contract. Every step type declares its required parameters, their types and ranges, and which of your tenant’s records they reference. Saving a step with a missing or misnamed required parameter, a group/schedule/category id that doesn’t exist, a fails with an error naming the step number and the bad key — it never saves green and then misfires in production.

• The step palette only offers steps that actually execute. Anything listed can run; there are no paper-only step types.

Dry-running before you activate

The Dry-run preview panel answers “would this run, and what would it do?” with no side effects — nothing is written, no provider is called, nobody is notified.

• Test against a real ticket. Enter a ticket id in the panel and the dry-run loads that ticket’s actual field values (your tenant only). Any sample fields you type override on top. Dry-running the seeded “New-incident enrichment” journey against an already-assigned incident, for example, honestly reports would not run with the reason.

• Trigger scope is checked too. A journey scoped to certain ticket types (the trigger’s “Applies to” list) previews “would not run” when the sample ticket’s type is outside that scope — with the reason naming the scoped types — instead of validating a journey that would never fire on that ticket.

• Errors appear next to the offending step. A step whose parameters break the contract, or whose referenced group/endpoint doesn’t resolve, is flagged inline with the exact errors, and the verdict is downgraded to “would not run” with a reason — a dry-run with red in it is telling you the journey is broken, not that the sample didn’t match.

Running a manual journey on a ticket

A journey whose trigger is manual never fires on its own — it exists to be dispatched deliberately. On such a journey’s row, Run on a ticket… asks for a ticket id and fires the journey once against it (requires journeys.manage; the dispatch is audited as journey.manual_run). The run executes immediately and the step trace opens so you can watch what it did. The journey’s conditions still apply: a non-matching ticket produces a completed no-op run, never a bypass. Event-triggered journeys refuse manual dispatch — fire their event instead.

This is the second half of the dry-run story: preview with the dry-run, then confirm for real on one concrete ticket.

Editing a journey that has runs in flight

Runs execute a snapshot of the step list taken when the run started. If you edit a journey’s steps while runs are parked mid-flight (waiting on a timer, an approval, or a device job), those runs finish the exact sequence they started with — inserting a step before their position no longer makes them silently skip it, and shortening the list no longer makes them finish early.

When you save a step change to a journey with active runs, the studio shows a warning naming how many runs are still executing the previous version. That is information, not a block: decide whether to let them finish, or cancel them from the run inspector.

Every run shows which definition version it executes (v3) in the run inspector and on the ticket’s journey panel. Runs older than the snapshot feature are marked as carrying a best-effort reconstructed snapshot.

Steps that wait for delivery confirmation

Two step types hand work to a delivery ledger with its own retries, and the run waits for the ledger to confirm instead of claiming success the moment the work was queued:

delivery confirmation”) while the outbox delivers with retries and backoff. When the receiver accepts, the step completes and the timeline says “delivered … (confirmed)”. If every retry is exhausted (or the endpoint was deleted), the step fails, the timeline states the downstream action was not confirmed, and the run fails — any later step that would have told the requester the action happened never runs. Fix the endpoint (Manage → Integrations → Webhooks) and re-trigger the journey.

• Send notification — the in-app inbox copy lands immediately; if an email or chat copy is queued, the run waits until those lanes settle and the step then reports exactly which channels delivered. A failed email is

While a run is waiting on a delivery, the run inspector shows it waiting at that step with the step still pending. This is expected — it is the product refusing to say “done” before it knows.

Steps that reach nobody say so. A notification whose recipient cannot be resolved (or who has turned every channel off), an on-call assignment against an empty rota, an escalation with no applicable policy, and a chat reply with no bound conversation each write a “reached nobody” entry on the ticket timeline and an audit record — never only a silent green step.

Seeing journey activity from the ticket

The desk ticket view has an Automation panel listing every journey run on the ticket — status, outcome, version, and, for a failed run, the error and the step it failed on. A failed or abandoned run also appears loud on the ticket timeline (never collapsed into the “N automation steps” summary), so an agent picking up the ticket cannot miss that an automation gave up.

The AI step and its confidence threshold

An ai_step with Auto-apply enabled exposes a Minimum confidence field (0–1, default 0.75): the provider’s stated confidence must clear it or the result is recorded as advisory only. Two honesty rules apply:

• Unknown confidence never auto-applies. A provider response that omits its confidence is treated as unknown quality, not certainty; the refusal is recorded with its reason on the AI invocation log.

• Every auto-applied change is visible. When the AI step changes a ticket’s category, impact, urgency, or priority, the ticket timeline shows which fields moved, old → new, with the confidence and threshold — and a full compliance record lands in the audit log (ai.auto_applied) with provider, model, and before/after values. An agent whose ticket’s priority moved can always see why.