Priority segment

Optional track — different routing to an operator by VIP / priority segment flag. You can add this to Use Case 13 as a capstone extension.

Required permissions and access

Module / setting	Why you need it
Scenario Builder	`switch` by segment before connect
Settings → Operator Panel	Two subjects with different `subject_alias`
Registered Users or Custom Data	Source of the segment flag
Instance Settings (optional)	Mock API token for `action_send_request`
Runs / Chat preview	Self-check segment A vs B

Business context

Priority customers (VIP, corporate, high LTV) should land in a different Operator Panel subject — with a separate queue or skill group. The scenario determines the segment and sets the matching subject_alias before connect.

Expected result

Segment flag source: Registered Users / Custom Data / mock API
Action switch with attention to type ('1' vs true, string vs number)
Node order: first check the segment, then subject_alias in connect
Different subject_alias for different connect blocks (or one connect with Set)

Link to other settings: each subject_alias is a subject in Settings → Operator Panel. Configure subjects

Architecture

Start → registered_users__get (or CD / API)
   ├─ success → switch (priority_segment)
   │     ├─ vip → Set subject_alias = training_vip
   │     └─ fallback → Set subject_alias = training_support
   └─ error → Set subject_alias = training_support (default)

Set subject_alias → operator_panel__connect_to_operator_with_msg
   ├─ success / limit / error

Step-by-step implementation

Step 0. Two subjects in Settings

Subject	Alias (example)	Purpose
Training Support	`training_support`	Regular customers
Training VIP	`training_vip`	Priority segment

Make sure both aliases exist before you build the scenario.

Step 1. Segment flag source

Choose one option for training:

Option	How to set the segment	Base Use Case
Registered Users	Field `priority_segment` = `1` or `vip`	Use Case 6
Custom Data	Customer record with a flag	Use Case 7
Mock API	JSON `{ "vip": true }`	Use Case 4

For a quick test: two Runs — one with the VIP flag, one without.

Step 2. Get the segment at start

Example — Registered Users:

Node	Action	Edges
1	`registered_users__get`	success → `switch`; error → default standard

In Runs, check the actual type of the value: '1' (string) vs 1 (number) vs true (boolean).

Step 3. `switch` — segment before connect

Node: Action switch (not Router — priority_segment is a profile/scenario value, not a request-context field).

Example params (adjust to the actual type in Runs):

{
  "vip": "'{{priority_segment}}' == '1' or '{{priority_segment}}' == 'vip'",
  "fallback": "1 == 1"
}

Edge	Action
`vip`	Set `subject_alias` = `training_vip`
`fallback`	Set `subject_alias` = `training_support`
`error`	Message / fall back to standard (see switch pitfalls)

Critical: do not set subject_alias in connect before this check.

Step 4. Connect with a dynamic alias

node_params	Value
`subject_alias`	`{{subject_alias}}`
`auto_connect_operator`	`true`

Edges: success + limit + error (as in Use Case 3).

Step 5. Self-check in Runs — two profiles

Run	Preparation	Expectation in constants
A	VIP flag in Registered Users	`subject_alias` = `training_vip`
B	Without VIP	`subject_alias` = `training_support`

In the connect trace, check which alias was passed to the action.

Troubleshooting

Symptom	What to check
Always standard	Variable type in Runs; `'1'` vs `1`
Always VIP	`switch` condition is too broad
Connect error	Alias exists in Settings for both subjects
Wrong queue in OP	Subject skill groups — configure-subjects

→ When it is not the scenario — if operators are not in the skill group, that is an OP setting, not the scenario.

Self-check

Runs: segments A and B lead to different subject_alias
Node order: segment → Set alias → connect
Edges limit and error have messages to the customer
Segment source recorded in the result template

Independent task

Add a third “corporate” segment with alias training_corporate and a mock API that returns { "tier": "corporate" }.