Journey Template Gallery

Scope

Journeys are deterministic: a trigger, conditions, and a fixed list of steps. This guide keeps the template gallery operating model and removes private execution internals.

Journeys are Beacon’s deterministic automation: a trigger, a set of conditions, and a fixed list of steps. The product experience is enable a template, not build a workflow. The the relevant workflow workspace has two tabs: the Template gallery and your Active journeys.

Enabling a template

1. Open Journeys and stay on the Template gallery tab.

2. Each card shows the category, whether it’s Scheduled, a plain-language description, and — always — the exception path: exactly when the journey hands off to a human. Read it; a journey with no honest exception path is not one you should trust.

3. Click Enable. If the template needs parameters (a routing group, a wait time, an approver), a panel slides over. Fill it in and click Enable journey. Templates with sensible defaults (e.g. a 72-hour aging threshold) pre-fill them.

4. The journey moves to Active journeys, switched on. Toggle it off any time.

Changing a running journey’s parameters

You do not have to disable and re-enable a template to change what it was set up with. On the Active journeys tab, a journey that came from a template shows an Adjust parameters action; it reopens the same form you filled in at enable time, pre-filled with what the journey is using now. Change a routing group, a wait time, or an approver and save — the journey is rebuilt from the template against the new values and starts behaving that way on its next run. Runs already in flight finish on the definition they started with.

Adjusting parameters is available to anyone who can enable templates, including the incident, problem, and change manager roles — you do not need the journey studio to retune automation you own. The version number on the row increments and the change is recorded in the audit log with the old and new values.

Custom journeys, hand-built in the studio, have no parameter form: edit them in the studio instead.

Cards marked Requires AI provider / identity provider / Relay connection are locked: they appear so you can see what’s coming, but they can’t be enabled (and never fake execution) until that capability is connected.

What ships enabled out of the box

Three of the sixteen templates are already on when your tenant is created. Every card in the gallery tells you whether it is on by default and why — and the ones that are not on tell you why not, which is usually the more useful half. Look for the On by default badge.

Enabled out of the box	What it does	How to stop it
Service-request aging escalation	On a schedule, flags service requests open past 72 hours without fulfillment and nudges the assignee, so requests never rot silently. Changes nothing on the ticket — it only adds an internal note and notifies.	Toggle it off, or disable and re-enable with a different threshold.
New-incident enrichment	Routes a newly raised incident to your Service Desk group (created for you at setup) and leaves an internal note saying it did. Only touches incidents that arrive unassigned — if an agent raised it already assigned to a specialist queue, this journey leaves it alone.	Toggle it off, or edit it to route somewhere else / drop the note step.
CSAT chase	Two hours after a ticket is resolved, invites the requester to rate their experience.	Toggle it off if you do not want automated survey mail.

Why the other thirteen are off

Nothing is off by accident. A template is only switched on for you if all three of these hold:

• It needs no decision only you can make. Templates that require an approver, an incident manager, an escalation group, or the name of one of your services cannot be sensibly defaulted — Beacon would have to guess, and a guessed approver is worse than no automation.

• It needs no connector you have not set up. Anything requiring a Relay connection, identity provider, IGA connector, or AI key stays locked until you connect one.

• It takes no action that is hard to undo. Anything that closes or resolves a ticket, provisions access, or runs a script on someone’s laptop is your call, not ours. That is why Stale resolved-ticket auto-close and Verified-problem auto-close ship off even though they would work immediately: closing a ticket stops SLA and CSAT clocks and ends the requester’s reopen window, and the right grace period is your policy, not a universal default.

If you would rather start from nothing

An administrator can set PROVISION_DEFAULT_JOURNEYS=false on the deployment so that new tenants are provisioned with no journeys at all. This does not affect tenants that already exist.

Existing tenants are never changed behind your back

If your tenant was created before a template became a default, you do not receive it retroactively — not at your next login, not ever. Beacon only applies the default set to a tenant that has no journeys at all, and if you delete a default journey it stays deleted. New defaults are something you opt into from the gallery, never something that appears on your desk one morning.

Auto-remediation for ingested alerts

With a device provider connected, enable Ingested-incident auto-remediation to close the loop on Relay alerts without a human in the middle: when an incident arrives through machine ingest, the journey waits briefly for the alert’s asset references to sync, restarts the service you configured on the exact machine that alerted, and resolves the incident when the provider reports success. A failed or timed-out restart assigns the ticket to your chosen escalation group with the full per-device job trace — the journey never claims success it didn’t verify. Operator-raised incidents never trigger it (it gates on the machine ingest source).

Scheduled (hygiene) journeys

Scheduled journeys run on a cadence instead of reacting to a single ticket. They select the open tickets that match their conditions and act on each one:

• Service-request aging escalation — nudge aging requests (above).
• Stale resolved-ticket auto-close — close incidents that have sat in Resolved with no activity for a grace period (default 7 days). Only resolved work is ever touched; reopening an incident excludes it.

How much a scheduled journey gets through in one run. A scheduled journey works through your open tickets in pages of 200, picking up on the next run where the last one stopped, and it keeps running back-to-back until it has been all the way round — only then does it wait out its interval. So on a queue of 1,000 open tickets an hourly journey still sees every ticket within a few minutes of its turn coming up; it does not take an hour per page, and it does not skip anything. Nothing is ever quietly excluded: every ticket that matches the journey’s conditions is evaluated on every lap. (Before this was fixed, a queue larger than 500 open tickets left an arbitrary remainder that scheduled automation never reached at all.)

Journeys that ask for approval

Some journeys pause for a human decision (the request_approval step). When one does, the run shows waiting in the run inspector and the approval appears in the Approvals tab of the the relevant workflow console for anyone with the Approvals permission. Approve resumes the journey from where it paused; Reject hands the work to a human (the run is recorded as escalated to human).

Watching journeys run

On the Active journeys tab, click Runs on any journey to open the run inspector. Each run shows its status, its honest outcome (resolved by journey vs escalated to human), and a per-step trace with any error. A running or waiting run can be cancelled — the cancellation is recorded on the ticket timeline.

The workspace is fully addressable: the tab lives at ?tab=gallery|active, an open run inspector at ?run=<journey id>, and the studio at ?edit=<journey id|new> — copy the URL and a reload (or a colleague) lands on the same view. Opening the inspector or studio adds a history entry, so the browser back button closes the drill-in instead of leaving the relevant workflow.

Building a custom journey (the studio)

When no template fits, engineers with the Manage journeys permission click New journey to open the authoring studio:

1. Basics — name it, pick a trigger (created / status change / resolved / schedule / external chat intent / manual), optionally restrict it to certain ticket types, and write the exception path (be honest about when a human takes over).

2. Conditions — add field / operator / value rows combined with ALL or ANY. Leave it empty to match everything. Temporal fields like days_since_update are available for schedule journeys.

3. Steps — add steps in order (assign, note, notify, transition, request approval, wait, escalate, run an AI action, …); each exposes just its relevant parameters. Reorder or remove any step. Every step after the first can be gated on the previous automation’s outcome: always, only if the previous automation succeeded, or only if it failed or timed out — that’s how you build an honest escalation tail.

4. Automation steps — Run a device job, Invoke a service action, and Send a templated chat reply are available too (they need a connected automation provider to activate). Device jobs and service actions must reference an entry in the journey’s Automation allowlists section — the audited ceiling of what the journey may run. Everything in an allowlist is a fixed reference: a canonical script picked from a list, a registered job kind, a provider-declared action. There is nowhere to type script text — that’s deliberate, and the server rejects any attempt. Chat replies pick from the code-owned template catalog; on tickets with no bound conversation they skip with an audit note instead of failing. The capability a journey needs is computed from its steps automatically — activation tells you exactly which provider is missing.

5. Dry-run preview — fill in a sample ticket and click Run preview. The studio shows whether the conditions would match and a plain-language line for every step — with no side effects (nothing is written, no AI is called). Iterate until it reads right, then Save (optionally flipping it Active).

Describe it (AI-assisted). If your tenant has connected a BYO AI provider (AI settings), the studio shows a Describe it panel at the top. Type what you want in plain language — “When someone reports a stuck print queue, clear the spooler on their device and let them know” — and click Propose with AI. The model drafts a complete journey strictly within Beacon’s fixed vocabulary (the same canonical scripts, job kinds, targets, and reply templates you’d pick by hand — never free-form script text) and drops it straight into the editor. A banner reminds you it’s AI-drafted — review before publishing, shows whether it passed the same validation your hand-authored journeys pass, and lists the connected capabilities it needs. Tick Only use capabilities I’ve connected to keep it to providers you actually have. From there it’s an ordinary draft: edit anything, dry-run it, and publish when it reads right. Nothing is saved or activated for you — the AI proposes, you decide. Without an AI provider the panel simply isn’t shown.

Studio work autosaves. Everything you build in the studio — basics, conditions, steps — is drafted to your browser (per tenant, per journey) as you edit. If you navigate away or reload mid-build, reopening the studio for the same journey (or New journey) offers Resume draft / Discard; nothing is silently restored, and the draft is cleared when the journey saves.

Custom journeys can be edited or deleted from the Active list; template-derived journeys show no Edit/Delete (retune them by re-enabling the template).

Getting around

The Journeys workspace header carries the workspace switcher, and when you arrive from a persona shell (the L2 Operations or L3 Engineering journey cards) it also shows ← Back to L2 Operations (or L3 Engineering) returning to the exact origin. The run inspector and studio show a small breadcrumb (Journeys → journey → Runs) so you always know where a drill-in sits.