Use Case 10: Ticket from bot + categorizer

Before you start: read Categorizer pattern. Complete this in the training bot after the basic level (Use Case 1–9).

Required permissions and access

Module / setting	Why you need it
Scenario Builder	Build the flow with categorizer and ticket create
Fast Line Pro	Categorizer agent (type “Chatbot”)
Settings → Tickets	Ticket subjects and `subject_alias`
Settings → Bots	Channel for testing (preview or Telegram)
Runs / Chat preview	Self-check: `ticket.id` after get_ticket_info, success/error edges

If Settings → Tickets is missing from the menu — check your account permissions or contact whoever manages access in your organization / ConnectiveOne support.

Business context

The customer describes a problem in free text in the bot. The system should automatically determine the request type, collect required fields, and create a ticket in ConnectiveOne. The ticket number must be available in Runs for further verification.

Expected result

Collection form: subject, description, priority
Categorizer → category variable → subject_alias via switch
action_tickets_create → edges success and error
After success: action_get_ticket_info → constant ticket
The customer receives a confirmation with the number via {{ticket.id}}

Architecture

MessageKeyboard ("Submit a complaint") → WaitForInput (subject, description, priority)
   → action_fastline_pro (categorizer) → switch by category
   → action_tickets_create
      ├─ success → action_get_ticket_info → "Ticket created: {{ticket.id}}"
      └─ error → "Could not create" + retry or end

Step-by-step implementation

Step 0. Ticket subjects in Settings

Link to other settings: subject_alias and ticket custom fields must match subjects in Settings → Ticket settings. Details: configure tickets.

Create (or reuse) subjects with aliases for training:

Alias (example)	Purpose
`training_payment`	Payment issues
`training_delivery`	Delivery issues
`training_damage`	Damaged product
`training_order`	Incorrect order

Write down the aliases — you need them in switch in step 5.

Step 1. Fast Line Pro — categorizer

Fast Line Pro → create an agent of type Chatbot (for example, “Training Ticket Categorizer”).
In the prompt, paste the text from categorizer-training.txt — section Use Case 10 (tickets).
Check in Agent testing: input “payment did not arrive” → output payment.

What the categorizer does: turns a free-form description into one category (payment, delivery, damage, order, other).

Fast Line Pro parameter	Value
Type	Chatbot (not Agent)
Prompt	categorizer-training.txt
Output in scenario	variable `ticket_category`

→ Fast Line Pro action

Step 2. MessageKeyboard — entry into the flow

Parameter	Value
Text	“Would you like to submit a request?”
Button	“Submit a complaint” · payload `ticket_start`
Keyboard type	inline

Edges: button → first WaitForInput node (subject).

Step 3. WaitForInput — collect fields

Use three nodes in sequence (or one with multiple fields if your instance supports it):

Node	messageText	outputVariable
1	“Briefly describe the request subject”	`ticket_title`
2	“Detailed problem description”	`ticket_description`
3	“Priority: low / normal / high”	`ticket_priority`

Validation: none for training (or limit priority to a list if needed).

Edges: last WaitForInput → Action categorizer.

Step 4. Action — `action_fastline_pro` (categorizer)

node_params	Value	Why
`agent_name`	`Training Ticket Categorizer`	Name from Fast Line Pro
`user_input`	`{{ticket_description}}`	Text to classify
`save_response`	`ticket_category`	Category for `switch`

Edges (required):

Edge	Where
Main output	Action `switch` (alias mapping)
fallback	MessageKeyboard: “Could not determine the type. Try rephrasing the description.”

Step 5. `switch` — map category to `subject_alias`

Node: Action switch (not Router — Router only works with request-context fields).

Example params (quoted string comparisons + fallback branch):

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

`switch` edge	Next
`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` (or an “other” subject)
`error`	Message about a condition error (see switch pitfalls)

After mapping — go straight to action_tickets_create.

Router does not fit here: ticket_category is a scenario variable, not a request-context field.

Step 6. Action — `action_tickets_create`

node_params	Value	Why
`subject_alias`	`{{subject_alias}}`	Ticket subject from Settings
`ticket_description`	`{{ticket_description}}`	Description (v2 API, if available)
`additional_fields`	title, priority per subject docs	Subject custom fields

On newer instances you may have action_tickets_create_v2 — check Node Inspector; the contract is similar.

Edges (required):

Edge	Where	Why
`success`	Action `action_get_ticket_info` (step 7)	After create, the id is not yet a constant for `{{…}}` in the message
`error`	MessageKeyboard: “Could not create the ticket. Check the data or try later.”	Without an error edge — silence

→ Actions reference — tickets

Step 7. Action — `action_get_ticket_info` + customer message

After ticket creation the id is kept for later ticket actions, but not as a ticket_id constant for MessageKeyboard placeholders. To show the number to the customer, fetch the ticket first:

node_params	Value	Why
`ticket_id`	(leave empty)	The action takes the last created ticket id from internal state

The action stores the ticket object in the ticket constant. Then — MessageKeyboard.

Edges:

Edge	Where	Why
`success`	MessageKeyboard: “Ticket created. Number: `{{ticket.id}}`”	Number from the `ticket` constant
`error`	MessageKeyboard: “Ticket created, but the number could not be retrieved. Contact support.”	Create already succeeded; get_info rarely fails

Do not use {{ticket_id}} right after create — the placeholder stays empty. Use {{ticket.id}} after action_get_ticket_info.

Troubleshooting in the scenario

Symptom	What to check
Edge `error` after create	`subject_alias` exists in Settings; subject custom fields; v1 vs v2 action
Empty number in the message	After create you have `action_get_ticket_info`; text uses `{{ticket.id}}`, not `{{ticket_id}}`
No `ticket` in Runs	Success edge create → get_ticket_info; constants show `ticket`
Categorizer returns “extra” text	Prompt — only one category word; test Fast Line Pro separately
“Sticky” chat_room_id	Create parameters: do not reuse an old room without logic; compare a new Run vs the same dialog

Details: Edge-driven flow · When it is not the scenario

Self-check (Runs)

Before moving to Use Case 11, make sure:

Three fields collected; trace shows ticket_title, ticket_description, ticket_priority
Categorizer: description “card does not work” → damage (or your category)
switch → correct subject_alias in constants
After create: action_get_ticket_info → Runs/constants has ticket with field id
Customer message shows the number via {{ticket.id}}
Create edge error: customer gets a message (simulate an invalid alias for the test, then restore the correct one)
Categorizer fallback does not leave the customer without a reply

Record the result in results-template.md.

Independent task

Add a rule: if the categorizer returned payment, automatically set ticket_priority = high before create (via Set on the payment branch of switch).

Reference links

Next step: Use Case 11: Broadcast