The entry flow

The front door. It greets the employee, confirms the record loaded at session start, and offers only the services they're entitled to — then routes to whichever they pick.

This is the gate-then-fan-out shape, and it's the right entry for anything with entitlements. Everything downstream assumes it ran.

Entry: gate, then fan out

StartStart

Agentgreet-and-confirm

Greet the employee by name and confirm the record loaded at session start.

confirmed→ offer-servicesnot_identified→ Transfer to HR

Agentoffer-services

Offer only the services this employee is entitled to, and route to the one they pick.

@Quick Replies

policy→ Policy Q&Aletter→ Letter flowcheckup→ Booking flownone_entitled→ Transfer to HR

1/1The entry flow on the canvas with its Start trigger open. The trigger is what makes the journey reachable, and it is set in the builder, not in the node.

The Start trigger

Unlike the other flows, this one isn't triggered by a topic — it's triggered by the conversation opening:

When the conversation begins, or when the employee asks what you can help with,
or asks for a menu of available HR services.

A flow is unreachable until its Start trigger is set. This is the most common reason a newly built entry flow never fires.

Node by node

greet-and-confirm — confirm what the hook loaded

greet-and-confirmAgent node

GoalGreet the employee by name and confirm the record loaded at session start.

Instructions

The employee record was loaded when the session started. Read {{employee}}.
- If it has a name, greet them by it once, briefly, and finish on confirmed.
- If it is empty, or its status says the lookup failed, say you can't confirm
their details right now and finish on not_identified. Do not treat this as
"no entitlements".
Do not list any services here — the next step does that.

Exitsconfirmednot_identifiedon_error

Variablesemployeeread

It confirms, it doesn't fetch. @getEmployeeDetails already ran in the session-start hook. This node's job is to handle the two outcomes — a record, or none.

"Do not list any services here" keeps the node to one job. Without it the model greets and offers, which duplicates the next node and produces two menus when only the second one's exits are wired.

offer-services — the entitled menu

offer-servicesAgent node

GoalOffer only the services this employee is entitled to, and route to the one they pick.

Instructions

Offer @Quick Replies built ONLY from the services listed in
{{employee.entitlements}}. Never offer an option you weren't given.

- When they pick one, finish on the matching exit.
- If nothing is listed, say HR will need to help and finish on none_entitled.
- If they ask for something outside the menu, hand back so routing can place it.

Send no message on the turn you exit.

Tools@Quick Replies

Exitspolicylettercheckupnone_entitled

VariablesemployeereadselectedServiceagent fills

Menu contents are data; menu destinations are exits. The list shown comes from employee.entitlements — a variable the hook wrote. The branches are the handful of real destinations. When the service catalogue grows next quarter you change a variable, not the flow.

Four exits, and that's near the ceiling. The limit is five per node, and accuracy drops before you reach it. A fifth service belongs in the entitlements list, not as a fifth branch — and if you genuinely need more destinations, group them two levels deep instead. See when the branches really do go ten different places.

selectedService is written for the flow it routes to. Each downstream flow's Start trigger reads it, which is what lets someone arrive at the letter flow either by picking it here or by asking directly.

Variables this flow uses

Variable	Scope	Written by	Read by
employee	global	the session-start hook	both nodes, and every other journey
selectedService	global	offer-services	the Start trigger of each downstream flow

selectedService has to be global — a journey variable would die when this flow hands over, which is exactly the moment the next flow needs to read it.

The unhappy paths

What happens	Where it goes	Why
Session-start lookup failed	not_identified → HR	A failed lookup is not "no entitlements". Denying a real employee is the worst outcome here
Entitlements list is empty	none_entitled → HR	A genuine business answer, but still needs a person
They ask for something off-menu	hand back to routing	The flow isn't a cage; routing can place it elsewhere
The run crashes	on_error → HR	Already present, just needs wiring

The distinction in the first two rows is the one to internalise, and you'll see it in every flow in this guide: a system failure and a business "no" must not share a path.

Test it

• A normal employee. Greeted by name, menu matches their entitlements.
• An employee with one entitlement. Menu shows one option, not four.
• A failed session-start lookup. Reaches a person — never a denial.
• "Actually, what's the leave policy?" mid-menu. Hands back rather than answering in place.

---

Next: The letter request flow.