Use Case 6: Реєстрація + повторний візит

Рівень: базовий · Модулі: Scenario Builder, Settings → Registered Users · Actions: registered_users__get, registered_users__check_phone, registered_users__set

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

Якщо розділу немає в меню — перевірте права облікового запису або зверніться до підтримки ConnectiveOne.

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

Перший візит — реєстрація (ім'я, опційно телефон); наступний — вітання по імені без повторного опитування.

Ключова ідея: змінні діалогу vs профіль клієнта

До Use Case 6 ви працювали з {{user_input}}, кнопками та API — це змінні поточного діалогу. Use Case 6 додає запам'ятати клієнта між зверненнями.

Preview vs канал. Кожен Run у Preview — новий клієнт (новий chat_id). Профіль шукається за chat_id + channel, тому другий Preview Run не побачить реєстрацію з першого. Повторний візит з вітанням по імені перевіряйте в реальному каналі (Telegram / віджет), де chat_id стабільний між діалогами.

Міні-приклад

1. Клієнт пише «Олена» → «Привіт, Олена!» — ім'я з змінної діалогу, все ок до кінця цього Run.
2. Клієнт повертається завтра в тому ж каналі (той самий Telegram / віджет):
   • без registered_users__set — бот знову «не знає» Олену;
   • з __set на першому візиті + __get на старті другого — «Вітаємо, Олена!».

Правило: все, що зібрали на реєстрації, збережіть через registered_users__set. На наступному візиті спочатку registered_users__get.

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

• registered_users__get на старті → success / error.
• error → збір даних → registered_users__set.
• success → «Вітаємо, {{client.first_name}}!»
• Повторний візит у каналі після реєстрації → __get success з тим самим ім'ям.

Архітектура flow

Start → registered_users__get
   ├─ success → «Вітаємо, {{client.first_name}}!»
   └─ error → WaitForInput (ім'я, телефон) → registered_users__check_phone → registered_users__set → «Дякуємо!»

Якщо збираєте телефон текстом: registered_users__check_phone перед registered_users__set. __set не нормалізує 050… → 380… — без check_phone номер збережеться як введено.

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

Крок 0. Registered Users — поля моделі

Settings → Registered Users → додати поля профілю (якщо ще немає):

Дані для запису (__set) потрапляють через constants reg_first_name, registration:first_name, reg_phone / registration:phone тощо. Для текстового телефону зазвичай outputVariable: reg_phone, потім registered_users__check_phone.

Як читати після __get (не плутати з записом): дія виставляє два обʼєкти — client (стандартні колонки профілю: first_name, phone, …) і registration (кастомні поля з колонки data). У повідомленнях використовуйте крапку: {{client.first_name}}. Плейсхолдер {{registration:first_name}} (з двокрапкою) після __get не заповнюється — це інший механізм (плоский ключ), його немає серед констант після читання.

На гілці реєстрації (до __get) звертайтеся до змінної введення з цього ж діалогу ({{reg_first_name}}), бо профіль ще не читали.

Крок 1. Action на Start — registered_users__get

Що робить: шукає профіль за chat_id + channel поточного діалогу; якщо знайдено — завантажує константи client (рядок профілю) і registration (обʼєкт data).

Edges:

Крок 2. Гілка error — збір даних

WaitForInput — ім'я

WaitForInput — телефон (опційно)

Action — registered_users__check_phone (якщо збирали телефон)

Edges: ланцюжок WaitForInput → registered_users__check_phone → registered_users__set.

Крок 3. Action — registered_users__set

Що робить: збирає constants профілю (registration:*, reg_*) і зберігає запис у БД Registered Users. Не нормалізує телефон — очікує вже підготовлений reg_phone після check_phone.

Edges:

Гілка error для __set у типовому сценарії немає (дія повертає success після збереження). Невалідний телефон обробляйте на registered_users__check_phone.

На цій гілці імʼя ще з змінної діалогу (reg_first_name). Після __get на наступному візиті використовуйте {{client.first_name}}.

Крок 4. Тест: Preview і повторний візит у каналі

A. Preview (гілка реєстрації)

1. Preview: пройти error → реєстрацію → success на __set.
2. (Опційно) Settings → Registered Users — є запис з ім'ям: __set спрацював.
3. Новий Preview Run: на Start __get знову error — очікувано. Preview щоразу створює нового клієнта; між Run профіль «не підхоплюється».

B. Канал (критерій повторного візиту)

1. Той самий користувач у Telegram або віджеті: перший діалог — реєстрація (__set success).
2. Другий діалог того ж користувача: на Start __get → success, {{client.first_name}} заповнене.

Без кроку B ви довели лише запис профілю, не розпізнавання при поверненні.

Критерії приймання (self-check)

• Preview Run: __get → error → реєстрація → check_phone success (якщо телефон) → __set success.
• Канал (той самий користувач, другий діалог): __get → success, ім'я відображається через {{client.first_name}}.
• Edges success і error на __get підключені.
• Для телефону: check_phone success / error підключені; 050… у Registered Users → 380….
• Для запису: reg_first_name / reg_phone (або registration:*) відповідають полям у Settings → Registered Users.

Типові помилки

Пов'язана документація

• Built-in actions — Registered Users
• Глосарій — registered_users
• FAQ — Registered Users
• Далі: Use Case 7 — Custom Data