Approvals is the gate between a finished journey and a live one. Anyone can build, but only an Admin or Manager can approve, and nothing publishes without a decision being recorded.

The queue

The queue lists journeys awaiting review. Each entry carries a risk level Xenia assigns automatically, and you can filter by risk or search by name.

Risk	Typically means
High	A large journey, with the guardrail situation called out explicitly
Medium	A moderate journey with normal blast radius
Low	A compact journey with few nodes and low operational risk

The risk note is written out, not just a badge. A high-risk journey with no safety rules is described as such, and reviewers are told to verify audience scope and frequency caps before approving. A high-risk journey that does have guardrails says how many.

Risk is a prompt for attention, not a verdict. It is derived from the journey's shape, so a small journey aimed at your entire customer base still deserves a careful read.

Reviewing

Read the briefing

The briefing is the author's statement of what the journey does and who it targets. If it does not tell you the audience, the channel, and the intent, send it back for that reason alone.

Open the journey

Reviewing takes you into the builder with the journey loaded, so you can inspect nodes, rules, and copy rather than approving a summary.

Check the blast radius

Who enrols, how many, how often, and what stops it. Confirm waits are sane, rules exclude who they should, and any recovery journey checks whether the thing it is recovering already happened.

Decide

Approve, or reject with a comment. Both are recorded against your reviewer role.

What happens next

Approved moves the journey to the Approved column, ready to publish.
Approve and publish does both in one step, taking the journey live immediately.
Rejected sends it to Review Rejected with your comment as the changes requested. The author fixes it and resubmits, which starts a fresh review.

Approval is not a substitute for simulation

A reviewer reads intent and scope. Whether the journey actually executes is what Simulation proves. Expect a journey to have been simulated before it reaches you, and ask if the author cannot say what the paths did.

Roles

Approving requires the Admin or Manager role. Other roles can see the queue but the decision actions are unavailable, rather than failing after the fact.

What the platform enforces regardless

Approval is a human check on top of automatic enforcement, not instead of it. Even an approved journey cannot send to someone without marketing consent, and per-person, per-channel frequency caps still apply at send time. A reviewer's job is the judgment those rules cannot make: whether this message, to these people, at this moment, is the right thing to send.

Journey Manager for moving work between stages
Journey Orchestrator for what the nodes do