> For the complete documentation index, see [llms.txt](https://docs.iexexchanger.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.iexexchanger.com/learn/email/02-events-routing.md).

# События, получатели и приоритет

## Что вы получите

Каждое используемое подключение будет отправлять только нужные события правильной аудитории. Вы зафиксируете приоритет, избежите дублирующих маршрутов и подготовите проверочную матрицу.

## Откройте список событий

На странице **«Настройки» — «Общие настройки» — «Уведомления» — «Подключения»** нажмите **«Включено: N»** в строке подключения.

{% hint style="info" %}
У Telegram-подключений **«Security-коды»** и **«Продолжение обмена»** в таблице указано **«Автоматически»**. Их события задаёт система, поэтому ручного каталога для них нет.
{% endhint %}

## Разделите аудитории

{% tabs %}
{% tab title="Клиентам" %}
Получатель определяется из конкретной заявки или связанного пользователя. Для E-mail нужен корректный адрес клиента. Для личного Telegram у системы должен быть chat ID: клиент предварительно запускает бота или проходит поддерживаемую привязку.
{% endtab %}

{% tab title="Администраторам" %}
Почта отправляется на адреса из **«Общих параметров»**. Telegram отправляется в чат, группу или канал, привязанный к конкретному подключению.
{% endtab %}
{% endtabs %}

Канал и группа Telegram предназначены только для команды. Клиентское событие через такое подключение не должно использоваться как способ передачи персональных данных.

## Выберите минимальный стартовый набор

Не включайте весь каталог одной кнопкой. Начните с событий, которые команда действительно умеет обработать.

| Проверка             | Пример бизнес-момента                    | Ожидаемая аудитория                      |
| -------------------- | ---------------------------------------- | ---------------------------------------- |
| Создание заявки      | Новая контрольная заявка сохранена       | Клиент и/или администратор по регламенту |
| Подтверждение оплаты | Клиент нажал разрешённое действие оплаты | Администратор                            |
| Изменение результата | Заявка исполнена или отклонена           | Клиент                                   |
| Новое сообщение      | Клиент написал оператору                 | Администратор или оператор               |
| Ошибка выплаты       | Автоматическая выплата не завершилась    | Администратор                            |

Названия каталога могут уточняться релизом. Выбирайте событие по его описанию и фактическому моменту возникновения, а не по похожему слову.

## Назначьте приоритет

| Приоритет в панели | Очередь                | Подходит для                                                                           |
| ------------------ | ---------------------- | -------------------------------------------------------------------------------------- |
| **«Высокий»**      | `notifications-high`   | События, требующие быстрого действия: безопасность, критическая ошибка, платёжный риск |
| **«Средний»**      | `notifications-normal` | Обычный ход заявки и сообщения команды                                                 |
| **«Низкий»**       | `notifications-low`    | Несрочные сводки и информационные события                                              |

Высокий приоритет выбирает более срочную очередь, но не гарантирует точную секунду доставки и не обходит ограничения провайдера.

## Настройте подключение по шагам

{% stepper %}
{% step %}

### Выберите одну аудиторию

Разверните **«Клиентам»** или **«Администраторам»** и включите одно понятное событие для первой проверки.
{% endstep %}

{% step %}

### Назначьте приоритет

Для обычной заявки используйте **«Средний»**. Высокий приоритет оставьте действительно срочным событиям.
{% endstep %}

{% step %}

### Проверьте соседние подключения

Убедитесь, что то же событие не включено случайно во втором SMTP, Resend или Telegram-маршруте.
{% endstep %}

{% step %}

### Сохраните окно

Нажмите **«Сохранить»**. Простое закрытие диалога не подтверждает изменение.
{% endstep %}

{% step %}

### Сверьте счётчик

В таблице должно появиться ожидаемое значение **«Включено: N»**. Откройте список повторно и убедитесь, что событие и приоритет сохранены.
{% endstep %}
{% endstepper %}

## Когда нужны несколько подключений

```mermaid
flowchart TD
    A["Одно событие"] --> B["Основная почта"]
    A --> C["Telegram команды"]
    A --> D["Вторая почта"]
    B --> E["Письмо получателю"]
    C --> F["Сообщение в чат"]
    D --> G["Ещё одно письмо получателю"]
```

Разветвление нормально, если разные каналы нужны по регламенту. Два почтовых маршрута с одной аудиторией обычно создают два письма, а не автоматическое переключение «основной → резервный».

{% hint style="warning" %}
Не выдавайте второму подключению те же события только ради отказоустойчивости. Сначала определите, как команда заметит отказ основного провайдера и кто вручную изменит маршрутизацию.
{% endhint %}

## Тексты и переменные

Событие определяет момент отправки и аудиторию. Клиентские тексты, статусные правила и подстановки готовятся в связанных разделах курса:

* [шаблоны валют и направлений](/learn/01-contacts/04-text-templates.md);
* [правила текстов по статусам](/learn/01-contacts/05-status-text-rules.md);
* [теги и пользовательские шорткоды](/learn/01-contacts/06-tags-shortcodes.md).

Не вставляйте в сообщение секретный ключ, полный пароль, внутреннюю метку оператора или данные чужой заявки. Предпросмотр текста не заменяет проверку реального события.

## Подготовьте матрицу проверки

| Подключение      | Событие          | Аудитория      | Приоритет | Контрольный получатель   | Факт доставки |
| ---------------- | ---------------- | -------------- | --------- | ------------------------ | ------------- |
| Основная почта   | Новая заявка     | Администраторы | Средний   | Контрольный ящик команды | Не проверено  |
| Основная почта   | Заявка исполнена | Клиент         | Средний   | Контрольный получатель   | Не проверено  |
| Telegram команды | Новая заявка     | Администраторы | Средний   | Рабочая группа           | Не проверено  |

Добавляйте строку только для реально включённой комбинации. После проверки фиксируйте время, ID заявки и конечный результат, но не секреты.

## Этап завершён, если

* [ ] у каждого события понятны момент и аудитория;
* [ ] канал или группа не используются для клиентских персональных данных;
* [ ] приоритет соответствует срочности;
* [ ] счётчик **«Включено: N»** совпадает с выбранными событиями;
* [ ] нет случайных одинаковых почтовых маршрутов;
* [ ] автоматические назначения Telegram не пытаются настраивать вручную;
* [ ] подготовлена матрица проверок реальных событий.

Теперь проверьте [доставку, очереди и восстановление](/learn/email/03-delivery-operations.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.iexexchanger.com/learn/email/02-events-routing.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.