Internal events trigger reference
This reference lists all internal event types and eventConfig parameters for the Internal Events trigger of the Start node.
Tickets
Ticket created (ticket_created)
Description: The section runs when a new ticket is created in the system.
eventConfig parameters:
| Parameter | Type | Description |
|---|---|---|
| channelFilter | string | Channel filter: '' (all), telegram, facebook, whatsapp |
| clientType | string | Client type: '' (all), new, existing |
Event data in context: chat_room_id, channel, bot_id, ticket data.
Ticket updated (ticket_updated)
Description: The section runs when ticket parameters change (status, priority, tags, etc.).
eventConfig parameters: Same as ticket_created (channelFilter, clientType), if supported in UI.
Ticket status name changed (ticket_status_name_changed)
Description: The section runs when the ticket status name changes.
eventConfig parameters: General filters (channelFilter, clientType).
Ticket subject changed (ticket_subject_changed)
Description: The section runs when a ticket's subject changes — by an operator in the Operator Panel, by a scenario (the "Update ticket" node), or by an integration or custom action.
When it runs:
- an operator changes the ticket subject or picks a subject when closing the ticket;
- the ticket is transferred to a skill group and its subject switches to that group's subject;
- the "Update ticket" node or a custom action writes a new subject;
- the subject is cleared ("no subject") or set on a ticket that had none — the empty side comes as
null.
Does not run:
- when the same subject that is already set is written again;
- for regular dialogs (not tickets) and when a dialog is converted to a ticket — use
ticket_createdfor that; - for a room that has no ticket yet.
eventConfig parameters: no extra filters (an empty eventConfig is valid).
Event data in context: ticket, ticket_id, chat_room, bot_id, channel, chat_id and the fields:
| Field | Description |
|---|---|
| chat_room_id | Ticket room ID |
| old_subject_id | Previous subject ID or null |
| new_subject_id | New subject ID or null (subject cleared) |
| old_subject_name | Previous subject name or null |
| new_subject_name | New subject name or null |
| actor_op_user_id | Operator ID if an operator changed the subject; otherwise null |
| change_source | Who changed the subject: operator, scenario (the "Update ticket" node), system (custom actions, integrations, sync with external systems) |
Important:
- The event does not send a Notification Center notification (bell). The existing subject-change notification works as before.
- The event does not start sections subscribed to
ticket_updated. - If a section syncs the subject to an external system (e.g. Jira) and that system writes the subject back, the section can start itself again. Break the loop by filtering on
change_source(e.g. react only tooperator) or onactor_op_user_id.
Ticket reassigned (ticket_reassign)
Description: The section runs when a ticket is reassigned to another operator.
eventConfig parameters:
| Parameter | Type | Description |
|---|---|---|
| channelFilter | string | Channel filter |
| clientType | string | Client type |
| operatorRole | string | Operator role: '', operator, supervisor, admin |
| team | string | Team: '', support, sales, tech |
Ticket reopened (ticket_reopened)
Description: The section runs when a closed ticket is reopened.
eventConfig parameters: General filters.
Ticket message (ticket_message)
Description: The section runs when an operator or a client (Client Portal, widget, email, messengers) adds a public new message to a ticket.
Does not fire for: operator internal notes, system messages, or service events with system_alias (reassignment, status change, etc.). For internal notes, use ticket_internal_note.
eventConfig parameters: No extra filters in MVP (empty eventConfig is valid).
Event data in context: ticket, ticket_id, chat_room, chat_room_id, bot_id, channel, message_id, message_text, message_type, message_from (operator | client), user_id, client_id, participant_id.
Internal note in ticket (ticket_internal_note)
Description: The section runs when an operator adds an internal note to a ticket (visible only to the team in Operator Line; the client does not receive it).
When it fires: only when a new note is created (not on edit). Does not fire for public operator replies, client messages, or service system events (reassignment, status change, etc.).
eventConfig parameters: No extra filters in MVP (empty eventConfig is valid).
Event data in context: ticket, ticket_id, chat_room, chat_room_id, bot_id, channel, message_id, message_text (note text preview, up to 150 characters), message_type, message_from (always operator), user_id, participant_id. client_id is always empty.
Important:
- The event does not send Notification Center alerts (bell) and does not deliver the note text to the client.
message_textis available in the scenario — if later steps send it to an external channel (email, messenger, webhook), you are responsible for keeping internal information confidential.- Chat Reminder does not treat an internal note as a public operator reply: the reminder timer is not stopped by a service note. Stopping still requires a public reply to the client.
Difference from ticket_message:
| Event | What triggers the section |
|---|---|
ticket_message |
Public message from operator or client |
ticket_internal_note |
Operator internal note only |
SLA and escalations
TFR escalated (TFR_escalated)
Description: The section runs when TFR (Time to First Response) is escalated.
eventConfig parameters: General filters, possibly deadlineMinutes, slaType (if supported).
TTC escalated (TTC_escalated)
Description: The section runs when TTC (Time to Close) is escalated.
eventConfig parameters: Same as TFR.
Time in status exceeded (time_in_status_exceeded)
Description: The section runs when a ticket has been in the selected status longer than the specified time.
eventConfig parameters:
| Parameter | Type | Description |
|---|---|---|
| statusId | number | Status ID from the instance status list |
| statusName | string | Status name (e.g. "Open") |
| timeInSeconds | number | Time in seconds (e.g. 7200 = 2 hours) |
| timeConfig | object | Breakdown: hours, minutes, seconds |
| triggerChannels | string[] | Channel array: ['telegram', 'viber'] or empty — all |
Example:
{
"statusName": "Open",
"timeInSeconds": 7200,
"triggerChannels": ["telegram", "viber"]
}
Closure
Chat closed (chat_closed)
Description: The section runs when a chat is closed.
eventConfig parameters: General filters.
Ticket closed (ticket_closed)
Description: The section runs when a ticket is closed.
eventConfig parameters: General filters.
Messages
Message delivery error (message_delivery_error)
Description: The section runs when a message delivery fails through e-chat (Telegram, Viber, WhatsApp).
eventConfig parameters:
| Parameter | Type | Description |
|---|---|---|
| channelFilter | string | Channel filter: '', telegram, viber, whatsapp |
| errorCodes | string[] | Array of e-chat error codes. Empty — all errors |
E-chat error codes:
| Channel | Code | Description |
|---|---|---|
| Viber | 2 | Number not in use |
| Viber | 3 | Temporary error |
| Viber | 4 | Blocked |
| Viber | 5 | Pending |
| Viber | 6 | Cannot chat |
| Viber | 7 | New number |
| Telegram | 4 | Blocked |
| — | Various error strings |
Event data in context: chat_room_id, message_id, channel, error_code, error_description, bot_id.
Example:
{
"channelFilter": "viber",
"errorCodes": ["2", "4"]
}
Clients
Client updated (client_updated)
Description: The section runs after a client card is saved in the Operator Panel — a card field or a custom field changed. Works for regular dialogs and tickets, and also when the card is edited from the clients list with no dialog open.
Does not fire for: a save that changed nothing, and client changes made by a bot or an import outside the Operator Panel card.
eventConfig parameters: none in this version (an empty eventConfig is valid). Filter inside the section using the event data below.
Event data in context:
| Field | Description |
|---|---|
| client_id | Client id |
| client | Client card after the save (email, phone, username, bot_name, extra_data, …) |
| bot_id | Process the client belongs to |
| user_id | Operator who saved the card |
| chat_room_id | Dialog the card was edited from, or empty |
| changed_fields | List of changed fields, e.g. ["email", "extra_data.crm_id"] |
| changes | Old and new value per changed field: {"email": {"old": "…", "new": "…"}} |
| extra_data | Custom fields after the save |
| source_module | Origin of the save when the caller supplies it (for example operator_panel), otherwise empty — the clients list does not send it |
Example — reacting to one custom field:
{{ trigger_data.changed_fields }} contains "extra_data.crm_id"
{{ trigger_data.changes["extra_data.crm_id"].new }}
If a section triggered by this event edits the same client card back through the Operator Panel API, it triggers itself again. Filter by
source_moduleor bychanged_fieldsto break the cycle.
Delivery is best-effort. The event is published after the card has already been saved, and publishing never delays or fails the save. If the event queue is unavailable at that moment, the card is still saved but the event is lost — there is no retry. For data that must never be missed, pair the event with a periodic reconciliation instead of relying on it alone.
Quality
AI QA assessment completed (qa_assessment_completed)
Description: The section runs when AI quality assessment of a closed dialog finishes successfully. Use this when you need the score and summary in CRM or a webhook. The chat-closed event often fires earlier, while assessment is still in progress.
Does not fire for: a failed assessment, an assessment that is still pending or processing, or a score entered only by a person without AI evaluation.
eventConfig parameters: none in this version (an empty eventConfig is valid). Filter inside the section using the event data below.
Event data in context:
| Field | Description |
|---|---|
| assessment_id | Assessment id |
| checklist_id | Checklist used for the assessment |
| chat_room_id | Dialog that was assessed |
| bot_id | Process the dialog belongs to |
| operator_id | Operator whose dialog was assessed |
| score | Score to send first: final, otherwise calculated, otherwise AI score |
| final_score | Final score when present |
| calculated_score | Calculated score when present |
| ai_score | AI score when present |
| dialog_summary | Short AI summary of the dialog |
| evaluation_status | Always completed for this event |
Example — send score to CRM after close:
Start → Internal events → AI QA assessment completed
then a send/request node with {{ trigger_data.score }} and {{ trigger_data.dialog_summary }}
Delivery is best-effort. Publishing never delays or fails the assessment. If the event queue is unavailable, the assessment is still saved and the event is lost — there is no retry. A second successful AI evaluation of the same dialog fires the event again.
General parameters (channelFilter, clientType, operatorRole, team, slaType)
These parameters may be available for various events in the UI:
| Parameter | Possible values |
|---|---|
| channelFilter | '', telegram, facebook, whatsapp |
| clientType | '', new, existing |
| operatorRole | '', operator, supervisor, admin |
| team | '', support, sales, tech |
| slaType | '', first-response, resolution, escalation |