Key platform concepts

Do not read the whole file at once — only the subsection before the matching Use Case.

Subsection	When to read
Edge-driven flow	Before Use Case 2 and later
Branching: edges / Router / switch	Before Use Case 2, Use Case 4, Use Case 10
AI Assistant and Knowledge base	Before Use Case 1; reminder after UC-1…4
Mock vs production API	Before Use Case 4
Categorizer pattern	Before Use Case 10
Broadcast vs scenario entry	Before Use Case 11

Dialog variables vs Registered Users — in Use Case 6.

Edge-driven flow {#edge-driven-flow}

ConnectiveOne is edge-driven: after an Action, execution follows the branch (edge) you connected on the canvas.

Node type	Must handle
Action (API, custom)	`success` + `error`
operator_panel__connect_to_operator_with_msg	`success` + `limit` + `error`
registered_users__get	`success` + `error`
action_fastline_pro	AI reply + fallback
action_tickets_create	`success` + `error`
Router	each rule + default branch (request-context fields)
`switch`	each condition branch + a fallback exit (see switch)
MessageKeyboard	each button or default

Principle: a scenario must not end without a message to the client. If an edge is not connected — the bot can go “silent” (see Use Case 9).

→ Built-in actions

Branching: edges / Router / switch {#router-branching}

Approach	When to use
Edges from MessageKeyboard	Button menu — a separate edge per button + default for free text (Use Case 2)
Router (`action_router`)	Branching by request-context fields in the Node Inspector: channel, request type, status, priority, subject, tags, etc.; `first_match` mode + default branch
Action `switch`	Branching by a scenario constant / variable (`user_choice`, `ticket_category`, API response) in an Action node — convenient for JSON / imported scenarios

In training:

button menus → edges (not Router);
saved scenario variable → switch (not Router);
channel / status / request tags → Router.

In older scenarios you may see if_else (conditions + else). For new flows by a variable prefer switch.

→ Conditional branches (Router) · Built-in actions — switch

AI Assistant and Knowledge base {#instance-agent}

Tool	Where	Why in training
Knowledge base (Fast Line Pro)	Fast Line Pro → Knowledge base	Documents for FAQ (Use Case 1); wait for indexing
AI Assistant (Instance Agent)	“Spark” icon in Scenario Builder	Node explanations; optionally — rebuild UC after manual implementation

Rule: build the Use Case by hand → self-check in Runs → optionally the same UC via Agent and compare. The Agent does not replace the first pass.

→ What is AI Assistant · FAQ — Instance Agent

Mock vs production API {#mock-vs-production-api}

For Use Case 4, a mock API is enough — you do not need a real CRM.

Approach	When	Example
Public mock	Training, first integrations	JSONPlaceholder
Webhook inspector	See the request	webhook.site
Instance Settings + URL	CRM simulation with a token	`training_api_token` + mock URL
Production CRM	Real project	After the basic level

→ Action Jail — integrations

Categorizer pattern {#categorizer-pattern}

Input: free-form client text.
Output: category or subject_alias.

Fast Line Pro (Chatbot) + categorizer prompt
action_fastline_pro → variable ticket_category
switch (on ticket_category) → map to ticket subject

Use Case 10: categorizer before action_tickets_create.

Broadcast vs scenario entry {#broadcast-vs-scenario-entry}

Path	When
Alias entry + Broadcast template	Use Case 11 — one-time/mass broadcast
`action_broadcast__subscribe`	Subscribe to a topic
`send_after` / `one_time`	Delayed / one-time delivery

The alias must match exactly between the scenario and the template.

→ Configure broadcast alias