Use Case 6: Registration + return visit

Level: basic · Modules: Scenario Builder, Settings → Registered Users · Actions: registered_users__get, registered_users__check_phone, registered_users__set

Required permissions and access

If a section is missing from the menu — check your account permissions or contact ConnectiveOne support.

Business context

First visit — registration (name, optionally phone); next visit — greet by name without asking again.

Key idea: dialog variables vs customer profile

Until Use Case 6 you worked with {{user_input}}, buttons, and API — these are current dialog variables. Use Case 6 adds remembering the customer across visits.

Preview vs channel. Each Preview Run is a new customer (new chat_id). The profile is looked up by chat_id + channel, so a second Preview Run will not see the registration from the first. Verify the return visit (greet by name) in a real channel (Telegram / widget), where chat_id stays stable across dialogs.

Mini example

1. Customer writes “Olena” → “Hi, Olena!” — name from a dialog variable, fine until the end of this Run.
2. Customer returns tomorrow in the same channel (same Telegram / widget):
   • without registered_users__set — the bot again “doesn’t know” Olena;
   • with __set on the first visit + __get at the start of the second — “Welcome, Olena!”.

Rule: everything you collected at registration, save via registered_users__set. On the next visit, start with registered_users__get.

Expected result

• registered_users__get at start → success / error.
• error → collect data → registered_users__set.
• success → “Welcome, {{client.first_name}}!”
• Return visit in a channel after registration → __get success with the same name.

Flow architecture

Start → registered_users__get
   ├─ success → “Welcome, {{client.first_name}}!”
   └─ error → WaitForInput (name, phone) → registered_users__check_phone → registered_users__set → “Thank you!”

If you collect phone as text: run registered_users__check_phone before registered_users__set. __set does not normalize 050… → 380… — without check_phone the number is saved as entered.

Step-by-step implementation

Step 0. Registered Users — model fields

Settings → Registered Users → add profile fields (if not yet):

Data for write (__set) reaches the action via constants reg_first_name, registration:first_name, reg_phone / registration:phone, etc. For typed phone, use outputVariable: reg_phone, then registered_users__check_phone.

How to read after __get (do not confuse with write): the action sets two objects — client (standard profile columns: first_name, phone, …) and registration (custom fields from the data column). In messages use a dot path: {{client.first_name}}. The placeholder {{registration:first_name}} (with a colon) is not filled after __get — that is a different mechanism (flat key), and __get does not create it.

On the registration branch (before __get), use the input variable from this same dialog ({{reg_first_name}}), because the profile has not been read yet.

Step 1. Action on Start — registered_users__get

What it does: looks up the profile by current dialog chat_id + channel; if found — loads the client constant (profile row) and registration (the data object).

Edges:

Step 2. error branch — collect data

WaitForInput — name

WaitForInput — phone (optional)

Action — registered_users__check_phone (if phone was collected)

Edges: WaitForInput chain → registered_users__check_phone → registered_users__set.

Step 3. Action — registered_users__set

What it does: collects profile constants (registration:*, reg_*) and saves the record in the Registered Users DB. Does not normalize phone — expects prepared reg_phone after check_phone.

Edges:

There is no error branch for __set in the typical scenario (the action returns success after save). Handle invalid phone on registered_users__check_phone.

On this branch the name still comes from the dialog variable (reg_first_name). After __get on the next visit, use {{client.first_name}}.

Step 4. Test: Preview and return visit in a channel

A. Preview (registration branch)

1. Preview: walk error → registration → success on __set.
2. (Optional) Settings → Registered Users — a record with the name exists: __set worked.
3. New Preview Run: on Start __get is error again — expected. Preview creates a new customer each time; the profile is not picked up across Runs.

B. Channel (return-visit criterion)

1. The same user in Telegram or a widget: first dialog — registration (__set success).
2. Second dialog from the same user: on Start __get → success, {{client.first_name}} filled.

Without step B you only proved that the profile was saved, not recognition on return.

Acceptance criteria (self-check)

• Preview Run: __get → error → registration → check_phone success (if phone) → __set success.
• Channel (same user, second dialog): __get → success, name is displayed via {{client.first_name}}.
• Edges success and error on __get are connected.
• For phone: check_phone success / error connected; 050… in Registered Users → 380….
• For write: reg_first_name / reg_phone (or registration:*) match fields in Settings → Registered Users.

Common mistakes

Related documentation

• Built-in actions — Registered Users
• Glossary — registered_users
• FAQ — Registered Users
• Next: Use Case 7 — Custom Data