---
title: "Priority segment"
description: "Optional: different scenario branches and subject_alias for regular and priority customers."
level: optional
track: priority-segment
prerequisites:
  - ../basic/use-case-03-handoff-to-operator.md
  - ../basic/use-case-06-registered-users.md
  - ../capstone/use-case-13-integrated-bot.md
---

# Priority segment

> **Optional track** — different routing to an operator by VIP / priority segment flag. You can add this to [Use Case 13](/en/learn/implementer/training/capstone/use-case-13-integrated-bot.md) as a capstone extension.

## Required permissions and access

| Module / setting | Why you need it |
|------------------|-----------------|
| **Scenario Builder** | Router 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
- Router / `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](/en/settings/how-to/configure-subjects.md)

## Architecture

```text
Start → registered_users__get (or CD / API)
   ├─ success → Router (priority_segment)
   │     ├─ priority → Set subject_alias = training_vip
   │     └─ standard → 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](/en/learn/implementer/training/basic/use-case-06-registered-users.md) |
| **Custom Data** | Customer record with a flag | [Use Case 7](/en/learn/implementer/training/basic/use-case-07-custom-data.md) |
| **Mock API** | JSON `{ "vip": true }` | [Use Case 4](/en/learn/implementer/training/basic/use-case-04-api-integration.md) |

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 → Router; **error** → default standard |

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

---

### Step 3. Router — segment **before** connect

**Node:** Router (`action_router`), mode `first_match` + default.

| Rule | Action |
|------|--------|
| `priority_segment` equals `1` **or** `vip` | Set `subject_alias` = `training_vip` |
| **Default** | Set `subject_alias` = `training_support` |

**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](/en/learn/implementer/training/basic/use-case-03-handoff-to-operator.md)).

---

### 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 | Router condition is too broad |
| Connect error | Alias exists in Settings for both subjects |
| Wrong queue in OP | Subject skill groups — [configure-subjects](/en/settings/how-to/configure-subjects.md) |

→ [When it is not the scenario](/en/learn/implementer/training/reference/when-not-scenario.md) — 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" }`.

## Reference links

- [Use Case 3 — handoff](/en/learn/implementer/training/basic/use-case-03-handoff-to-operator.md)
- [Use Case 6 — Registered Users](/en/learn/implementer/training/basic/use-case-06-registered-users.md)
- [Configure subjects](/en/settings/how-to/configure-subjects.md)
- [Edge-driven flow](/en/learn/implementer/training/concepts.md#edge-driven-flow)