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 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.
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 |