Автоматизация
Страница для администраторов. Правила автоматизации делают рутину за вас — «когда происходит вот это и выполняются такие-то условия, сделать вот то» — и не требуют программирования. Правила живут в разделе Админ → Автоматизация.
Из чего состоит правило
У каждого правила три части:
| Часть | Что определяет |
|---|---|
| Триггер | Что запускает правило. |
| Условия | Стоит ли продолжать в этот раз. |
| Действия | Что правило делает. |
Триггеры
Событие — что-то произошло в системе. Список в форме сгруппирован:
Группа Что попадает Задача Создана, переведена в статус, изменена (в том числе сменился исполнитель), удалена, прокомментирована, комментарий изменён или удалён, добавлено или снято вложение, связь, наблюдатель. Проект Создан, изменён, удалён, добавлен или убран участник роли. Доска Создана, изменена, удалена, изменена или переставлена колонка. Вебхук Пришёл входящий вебхук. Прочее Загрузка файла завершена; события, которые приносят включённые функции, — например, входящее письмо. У задач, проектов и досок есть вариант «любое событие этой группы» — удобно, когда правило интересует всё, что происходит с объектом.
Расписание — правило срабатывает периодически, ничего не дожидаясь; может проходить по выборке задач.
Вручную — вы запускаете его сами кнопкой «Запуск» в списке правил.
Расписание по выборке задач
У правила по расписанию есть поле «Выборка задач» — список сохранённых фильтров. Выберите фильтр, и на каждом срабатывании правило пройдёт по каждой найденной задаче: условия и действия выполнятся для неё, а в журнале прогонов появится отдельная строка на задачу.
Так делается регулярный обход: «просроченные — пометить», «висящие на согласовании дольше недели — вернуть в работу», «закрытые месяц назад — в архив». Раньше это требовало внешнего скрипта: правило по расписанию запускалось один раз и ни о какой задаче не знало.
- Пункт «Без выборки (один прогон)» — прежнее поведение: одно срабатывание, задачи в контексте нет.
- Число задач за один проход ограничено (по умолчанию 200) — фильтр без условий не должен превращаться в проход по всей базе. Предел задаётся конфигурацией.
- Задачи обрабатываются по очереди, а не разом.
- Если фильтр удалён или стал недоступен, в журнал пишется, что выборка недоступна, — тик при этом не падает.
У прогона по расписанию нет автора
Событие никто не вызывал, поэтому действия идут служебным доступом. Годится всё, что не требует автора: метки, поля, статусы, письма, внешние вызовы. Добавить комментарий так нельзя — у комментария должен быть автор. Отсюда и шаблон «Ночной обход просроченных» ставит метку, а не пишет комментарий.
Входящий вебхук как триггер
Событие, которое породил входящий вебхук, запускает правило так же, как внутреннее. Порядок такой:
- Завести хук в Админ → Вебхуки и отдать выданный адрес внешней системе.
- Дождаться настоящего вызова и посмотреть тело запроса в журнале вызовов.
- В правиле выбрать триггер-вебхук и указать имя своего хука вместо
*. Иначе правило сработает на любой вебхук инстанса — редко то, что нужно. - Условиями разобрать тело: поля вебхука доступны отдельной группой, а до произвольного места в теле добирается «Свой путь» — см. Условия.
Входящее письмо как триггер
Если включён приём писем, письмо клиента тоже становится событием. Правилу доступны отправитель и его домен, адрес получателя, тема, текст, вердикты проверок подлинности (DMARC, SPF, DKIM), признаки «спам» и «автоответ», а также In-Reply-To — по нему отличают первое обращение от ответа в существующую переписку.
Условия
Условия образуют дерево, а не плоский список: они объединяются через И / ИЛИ, любую ветвь можно инвертировать. Поэтому правило спокойно выражает «высокий приоритет и при этом либо нет исполнителя, либо срок просрочен», не превращаясь в набор костылей. Операторов сравнения много — равенство, порядок, вхождение, пустота, «изменилось» и другие; набор зависит от того, какое поле вы сравниваете.
Поля для сравнения сгруппированы: поля события (что изменилось, из какого статуса в какой), задачи, проекта, автора действия, комментария, а также поля вебхука и письма, если правило запускается ими. Отдельная группа — условия функций: их приносят включённые функции, см. ниже.
Свой путь — когда нужного поля в списке нет
Пункт «✎ указать путь вручную…» позволяет сравнить любое значение из события. Так разбирают тело произвольного вебхука: тело лежит в payload.body, заголовки — в payload.headers, то есть путь к полю выглядит как payload.body.action. Что именно прислал отправитель, видно в журнале вызовов на странице Админ → Вебхуки.
Действия
Встроенных действий два десятка, и в форме они разложены по группам:
| Группа | Что умеет |
|---|---|
| Задача | Назначить и снять исполнителя, задать соисполнителей; сменить статус, приоритет, тип, срок, оценку; добавить и убрать метку; добавить комментарий (в том числе внутренний); добавить и убрать наблюдателя; связать задачи; создать новую задачу — в том числе подзадачу. |
| Внешние каналы | Отправить письмо; вызвать внешний адрес — свой метод, заголовки и тело. Токены для вызова лучше держать в секретах: {{secret.ИМЯ}} получает настоящее значение только здесь, а в журнале и сухом прогоне выглядит как ***. |
| Управление | Остановить, если — прервать оставшуюся часть правила при выполнении условия. Пауза — приостановиться и продолжить позже: отложенные шаги подхватываются, когда приходит их срок, поэтому «если через 2 дня ничего не изменилось — эскалировать» умещается в одно правило. |
| Отладка | Записать текст в журнал прогонов — чтобы видеть, что правило дошло до этого места и с какими значениями. Здесь же произвольный запрос к API продукта — крайнее средство для того, чего не покрывают остальные действия. |
Поля действий принимают подстановки вида {{issue.key}}, {{actor.id}}, {{mail.subject}} — значение берётся из события, ради которого правило запустилось.
Наберите две открывающие скобки
Поля, куда подставляются значения, подсказывают сами: наберите {{ — и выпадет список доступных путей с описаниями; кнопка со скобками в углу поля открывает тот же список с поиском и группировкой. Искать можно и по переводу («приоритет»), а не только по имени поля. Под полем показывается разбор набранного и предпросмотр значения.
Список не ограничивает ввод: путь, которого в нём нет, помечается как отсутствующий в справочнике, но принимается — иначе были бы недоступны поля тела произвольного вебхука.
Это не плейсхолдеры писем-уведомлений
Скобки те же, а наборы имён разные и не пересекаются: в правиле это путь по событию ({{issue.key}}), в шаблоне письма-уведомления — короткое имя из закрытого словаря ({{issueKey}}). Чужое имя подставится пустой строкой.
Сверх этого действия приносят включённые функции — см. ниже.
Форма и схема
У формы правила два вида, переключатель — в её заголовке:
| Вид | Что показывает |
|---|---|
| Форма | Привычные списки: условия отдельно, действия отдельно. |
| Схема | Правило как цепочку: Триггер → Условия → Действие 1 → Действие 2 …. Клик по узлу открывает его настройки справа. |
Это два вида одного правила, а не два разных редактора: переключение ничего не теряет и ничего не сохраняет — сохранение общей кнопкой. На схеме сразу видно то, что в списках теряется: незаполненное обязательное поле подсвечено, а действие от выключенной функции помечено как «нет обработчика» — такое правило запишет ошибку в журнал.
Порядок действий на схеме — это и есть цепочка: перетащите связь с одного действия на другое, чтобы поставить его следом; клавиша Delete убирает выделенное действие.
Ветвлений в схеме нет намеренно
Правило выполняет действия по порядку и развилок не знает. Условная остановка — это действие «Остановить, если», а не вторая ветка на холсте: рисовать развилку, которой не будет в исполнении, значило бы обещать несуществующее поведение.
Если ядро инстанса обновлено не до конца, вкладки «Схема» может не быть вовсе — форма при этом работает как обычно.
Правило действует правами того, кто вызвал событие
Изменения выполняются от имени автора события, а не от имени администратора. Если у человека нет права на действие, шаг завершится ошибкой — это видно в журнале прогонов. Письма и чтение данных для условий идут служебным доступом, поэтому условия не зависят от того, кто именно нажал кнопку.
Шаблоны правил
Над списком правил есть карточка «Шаблоны правил» с типовыми сценариями: клик по шаблону подставляет готовый рецепт в форму — и ничего не сохраняет, пока вы не нажмёте сохранение сами. Взять шаблон и поправить его обычно быстрее, чем собирать правило с нуля, и заодно видно, как части складываются вместе.
| Шаблон | Что делает |
|---|---|
| Назначить на себя при старте | Взял задачу в работу — стал её исполнителем. |
| Эскалация критичных | Критичная задача при создании получает метку и уведомление. |
| Ответ клиента переоткрывает | Комментарий клиента возвращает закрытое обращение в работу. |
| Метка «залежалась» | Задача, которую давно не трогали, помечается. |
| Следить за своими изменениями | Кто изменил задачу, тот становится наблюдателем. |
| Ночной обход просроченных | По расписанию помечает задачи меткой. Выберите выборку задач — например, сохранённый фильтр «срок раньше начала дня и задача не завершена». |
| Отложенная проверка | Через двое суток проверяет, что задача всё ещё решена, и комментирует. |
| Комментарий подзадачи — в родителя | Дублирует комментарий из дочерней задачи в родительскую. |
| Задача из вебхука | Заготовка под внешнюю систему: замените * именем своего хука, укажите проект и пути к полям тела. |
| Обращение из письма | Письмо от доверенного отправителя с пройденным DMARC становится задачей. Укажите проект и домены клиентов. |
| Ответ клиента в тред | Письмо-ответ дописывается комментарием. Способ найти нужную задачу подставляете вы — например, ключ задачи в теме. |
| Карантин писем | Спам, письма без DMARC и автоответы уходят в отдельный проект на разбор человеком. |
Шаблон — это заготовка, а не готовое правило
Три последних сценария намеренно приходят с пустыми проектом и списком доверенных доменов: пустой список означает «ни от кого», и это лучше, чем правило, которое из коробки заводит задачи по любому письму из интернета. Заполните их своими значениями и проверьте сухим прогоном.
Действия и условия от других функций
Автоматизация не ограничена тем, что умеет сама. Другие функции регистрируют собственные действия и условия, и те появляются в форме правила сами, как только функция включена:
| Функция | Добавляет условия | Добавляет действия |
|---|---|---|
| Пользовательские поля | Сравнить значение поля по ключу | Установить значение поля |
| SLA | SLA нарушен; сколько минут до нарушения; таймер идёт | — |
| Service Desk | Статус согласования; оценка CSAT | Запустить согласование |
| Портфели | RAG-статус проекта; число просроченных контрольных точек проекта | — |
| Волны релизов | — | Установить статус бренда в волне |
| Уведомления | — | Оповестить участников задачи — исполнителей, наблюдателей или всех, их обычными каналами |
Функции приносят и собственные события для триггера: портфели — смена RAG-статуса, просроченная или приближающаяся контрольная точка; волны релизов — волна создана, задача или бренд добавлены в волну или убраны из неё, сменился статус бренда. Поля такого события (название бренда, прежний и новый статус и другие) доступны условиям и подстановкам наравне с остальными.
Если функция выключена или недоступна, её условия считаются невыполненными, а её действия завершаются ошибкой в журнале прогонов. Тихо отвалившаяся функция не приводит к массовому срабатыванию правил.
Проверка правила
Кнопки две, и разница принципиальна:
- Тест — сухой прогон. Условия проверяются на настоящих данных, а действия лишь сообщают, что они сделали бы. Ничего не меняется.
- Запуск — настоящий прогон с настоящими последствиями.
Прогон можно также повторить из журнала — удобно, когда правило не сработало из-за причины, которую вы уже устранили.
Журнал прогонов
Записывается каждый прогон: что его вызвало, сошлись ли условия, какие действия выполнились и какая была ошибка. Когда правило «не работает», ответ почти всегда есть в журнале — чаще всего это условие, не совпавшее с данными, или действие от выключенной функции.
Отправка писем из правила
Действию «Отправить письмо» нужен почтовый транспорт, который выбирается на этой же странице. Пока он не назначен, письма из правил не доставляются, а попытка попадает в журнал отправок. См. Почта → Назначение транспортов.
Журнал прогонов показывает, что правило отработало, но не следит за судьбой письма: если провайдер откажет позже, это будет видно только на странице Админ → Почта — в очереди отправки и журнале. Учтите и приоритет: у писем из правил он самый низкий, поэтому при загруженной почте массовая рассылка уходит последней и не задерживает сброс пароля и уведомления.
Петли и разогнавшиеся правила
Правила меняют задачи, а изменённые задачи запускают правила. От этого есть три независимые защиты: ограничение глубины цепочки собственных изменений, на которой правила ещё срабатывают; запрет самозапуска — правило не реагирует на событие, порождённое им самим, пока в нём не включена галочка «Разрешить самозапуск»; и ограничение того, сколько раз одно правило может отработать по одной задаче за промежуток времени. Значения по умолчанию первой и третьей защит разумны; изменить их можно в Конфигурации, если есть причина.
И всё же, когда правило правит задачи того же вида, на которые реагирует, добавьте условие, делающее второй проход бессмысленным. Защиты — это страховка, а не замена проектированию.
Что дальше
- Вебхуки — как впустить события внешних систем и как отправить свои наружу.
- Почта — транспорты для писем из правил и приём писем.
- Плагины — включение функций, приносящих условия и действия.
- Настройка проектов — статусы и поля, с которыми работают правила.
- Фильтры и сохранённые выборки — откуда берутся выборки задач для правил по расписанию.
Смотрите также
- Руководство агента → SLA — условия SLA, доступные правилам, и почему нарушение само никого не уведомляет.
- Задачи → Наблюдатели — одно из типовых действий правил со стороны пользователя.
- Функции и настройки → Журнал аудита — где видно, что именно изменило правило.
- Конфигурация → Ограничения автоматизации — значения защит от петель и период отложенных шагов.