---
title: "Internal events trigger reference"
description: "Complete list of internal event types and eventConfig parameters for the Start node trigger."
---

# 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_text` is 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:**

```json
{
  "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 |
| WhatsApp | — | Various error strings |

**Event data in context:** chat_room_id, message_id, channel, error_code, error_description, bot_id.

**Example:**

```json
{
  "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_module` or by `changed_fields` to 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` |

---

## Related documents

- [What is the Start node](/en/scenariobuilder/explanation/what-is-start-node.md)
- [Configure internal events](/en/scenariobuilder/how-to/configure-start-node-internal-events.md)
- [Configure Start node triggers](/en/scenariobuilder/how-to/configure-start-node-triggers.md)