Use Case 10: Тікет з бота + categorizer

Перед стартом: прочитайте Categorizer pattern. Виконуйте в навчальному боті після базового рівня (Use Case 1–9).

Необхідні права та доступ

Модуль / налаштування	Навіщо
Scenario Builder	Збірка flow з categorizer і create-тікета
Fast Line Pro	Categorizer-агент (тип «Чат-бот»)
Settings → Tickets	Теми тікетів і `subject_alias`
Settings → Bots	Канал для тесту (preview або Telegram)
Runs / Chat preview	Self-check: `ticket.id` після get_ticket_info, edges success/error

Якщо розділу Settings → Tickets немає в меню — перевірте права облікового запису або зверніться до того, хто керує доступами у вашій організації / до підтримки ConnectiveOne.

Бізнес-контекст

Клієнт описує проблему вільним текстом у боті. Система має автоматично визначити тип звернення, зібрати обов'язкові поля та створити тікет у ConnectiveOne. Номер тікета має бути доступний у Runs для подальшої перевірки.

Очікуваний результат

Форма збору: тема, опис, пріоритет
Categorizer → змінна категорії → subject_alias через switch
action_tickets_create → edges success і error
Після success: action_get_ticket_info → константа ticket
Клієнт отримує підтвердження з номером через {{ticket.id}}

Архітектура

MessageKeyboard («Подати скаргу») → WaitForInput (тема, опис, пріоритет)
   → action_fastline_pro (categorizer) → switch за категорією
   → action_tickets_create
      ├─ success → action_get_ticket_info → «Тікет створено: {{ticket.id}}»
      └─ error → «Не вдалося створити» + retry або завершення

Покрокова реалізація

Крок 0. Теми тікетів у Settings

Зв'язок з іншими налаштуваннями: subject_alias і custom fields тікета мають відповідати темам у Settings → Налаштування Тікетів. Детальніше: налаштувати тікети.

Створіть (або використайте) теми з alias для навчання:

Alias (приклад)	Призначення
`training_payment`	Проблеми з оплатою
`training_delivery`	Проблеми з доставкою
`training_damage`	Пошкоджений товар
`training_order`	Неправильне замовлення

Запишіть alias — вони потрібні в switch на кроці 5.

Крок 1. Fast Line Pro — categorizer

Fast Line Pro → створіть агента типу Чат-бот (наприклад, «Training Ticket Categorizer»).
У prompt вставте текст з файлу categorizer-training.txt — секція Use Case 10 (тікети).
Перевірте в Тестування агента: вхід «не прийшла оплата» → вихід payment.

Що робить categorizer: перетворює вільний опис на одну категорію (payment, delivery, damage, order, other).

Параметр Fast Line Pro	Значення
Тип	Чат-бот (не Agent)
Prompt	categorizer-training.txt
Вихід у сценарії	змінна `ticket_category`

→ Fast Line Pro action

Крок 2. MessageKeyboard — вхід у flow

Параметр	Значення
Текст	«Хочете подати звернення?»
Кнопка	«Подати скаргу» · payload `ticket_start`
Тип клавіатури	inline

Edges: кнопка → перша нода WaitForInput (тема).

Крок 3. WaitForInput — збір полів

Виконайте три ноди послідовно (або одну з кількома полями, якщо ваш інстанс підтримує):

Нода	messageText	outputVariable
1	«Коротко опишіть тему звернення»	`ticket_title`
2	«Детальний опис проблеми»	`ticket_description`
3	«Пріоритет: low / normal / high»	`ticket_priority`

Validation: none на навчанні (або обмежте пріоритет списком, якщо потрібно).

Edges: останній WaitForInput → Action categorizer.

Крок 4. Action — `action_fastline_pro` (categorizer)

node_params	Значення	Навіщо
`agent_name`	`Training Ticket Categorizer`	Ім'я з Fast Line Pro
`user_input`	`{{ticket_description}}`	Текст для класифікації
`save_response`	`ticket_category`	Категорія для `switch`

Edges (обов'язково):

Edge	Куди
Основний вихід	Action `switch` (мапінг alias)
fallback	MessageKeyboard: «Не вдалося визначити тип. Спробуйте переформулювати опис.»

Крок 5. `switch` — мапінг категорії на `subject_alias`

Нода: Action switch (не Router — Router працює лише з полями контексту звернення).

Приклад параметрів (рядкові порівняння з лапками + запасна гілка):

{
  "payment": "'{{ticket_category}}' == 'payment'",
  "delivery": "'{{ticket_category}}' == 'delivery'",
  "damage": "'{{ticket_category}}' == 'damage'",
  "order": "'{{ticket_category}}' == 'order'",
  "fallback": "1 == 1"
}

Edge `switch`	Далі
`payment`	Set `subject_alias` = `training_payment`
`delivery`	Set `subject_alias` = `training_delivery`
`damage`	Set `subject_alias` = `training_damage`
`order`	Set `subject_alias` = `training_order`
`fallback`	Set `subject_alias` = `training_order` (або тема «інше»)
`error`	Повідомлення про помилку умови (див. пастки switch)

Після мапінгу — одразу action_tickets_create.

Router тут не підходить: ticket_category — змінна сценарію, а не поле контексту звернення.

Крок 6. Action — `action_tickets_create`

node_params	Значення	Навіщо
`subject_alias`	`{{subject_alias}}`	Тема тікета з Settings
`ticket_description`	`{{ticket_description}}`	Опис (v2 API, якщо доступно)
`additional_fields`	title, пріоритет за docs теми	Custom fields теми

На нових інстансах може бути action_tickets_create_v2 — перевірте Node Inspector; контракт аналогічний.

Edges (обов'язково):

Edge	Куди	Навіщо
`success`	Action `action_get_ticket_info` (крок 7)	Id після create ще не в constants для `{{…}}` у повідомленні
`error`	MessageKeyboard: «Не вдалося створити тікет. Перевірте дані або спробуйте пізніше.»	Без error edge — тиша

→ Довідник actions — tickets

Крок 7. Action — `action_get_ticket_info` + повідомлення клієнту

Після створення тікета id зберігається для наступних ticket-дій, але не як константа ticket_id для плейсхолдерів у MessageKeyboard. Щоб показати номер клієнту, спочатку отримайте тікет:

node_params	Значення	Навіщо
`ticket_id`	(порожньо)	Дія візьме id останнього створеного тікета з внутрішнього стану

Action кладе об'єкт тікета в константу ticket. Далі — MessageKeyboard.

Edges:

Edge	Куди	Навіщо
`success`	MessageKeyboard: «Тікет створено. Номер: `{{ticket.id}}`»	Номер з константи `ticket`
`error`	MessageKeyboard: «Тікет створено, але не вдалося отримати номер. Зверніться до підтримки.»	Create уже пройшов; get_info рідко падає

Не пишіть {{ticket_id}} одразу після create — плейсхолдер лишиться порожнім. Використовуйте {{ticket.id}} після action_get_ticket_info.

Troubleshooting у сценарії

Симптом	Що перевірити
Edge `error` після create	`subject_alias` існує в Settings; custom fields теми; v1 vs v2 action
Порожній номер у повідомленні	Після create є `action_get_ticket_info`; у тексті саме `{{ticket.id}}`, не `{{ticket_id}}`
Немає `ticket` у Runs	Edge success create → get_ticket_info; у constants з’являється `ticket`
Categorizer повертає «зайве»	Prompt — лише одне слово категорії; перевірте Fast Line Pro окремо
«Залипання» chat_room_id	Параметри create: не перевикористовуйте старий room без логіки; порівняйте новий Run vs той самий діалог

Детальніше: Edge-driven flow · Коли не сценарій

Self-check (Runs)

Перед переходом до Use Case 11 переконайтеся:

Три поля зібрані; у trace видно ticket_title, ticket_description, ticket_priority
Categorizer: опис «картка не працює» → damage (або ваша категорія)
switch → правильний subject_alias у constants
Після create: action_get_ticket_info → у Runs/constants є ticket з полем id
Повідомлення клієнту містить номер через {{ticket.id}}
Edge error create: клієнт отримує повідомлення (симулюйте невалідний alias для тесту, потім поверніть коректний)
Fallback categorizer не залишає клієнта без відповіді

Зафіксуйте результат у results-template.md.

Самостійне завдання

Додайте правило: якщо categorizer повернув payment, автоматично встановлюйте ticket_priority = high перед create (через Set на гілці payment у switch).

Довідкові посилання

Наступний крок: Use Case 11: Broadcast