Применимость: Cloud. Названия пунктов и доступность функций зависят от версии, плана и типа проекта. Проверяйте изменения на тестовом окружении. Описанные рабочие процедуры — предлагаемый подход, а не гарантии поставщика.
Сценарий и границы ответственности
Команда сопровождения хочет каждый рабочий день видеть задачи с истёкшим сроком, которые ещё требуют действий. Первое решение обычно выглядит как расписание и комментарий во все найденные задачи. Через неделю обсуждения заполнены одинаковыми сообщениями, исполнители перестают их читать, а закрытые обращения иногда тоже попадают в выборку. Сначала определите деловой результат: одно напоминание на задачу за согласованный период, понятный адресат и отсутствие изменений в задачах, которые команда уже завершила. Автоматизация не должна самостоятельно переносить срок: это скроет нарушение исходного обязательства и исказит отчётность.
Зафиксируйте проект, рабочие статусы, часовой пояс команды и владельца правила. Для первого запуска достаточно одного проекта и отдельной метки пилота. Решите, требуется ли комментарий в задаче или персональное уведомление. Комментарий полезен для истории, но его видимость и уведомления необходимо проверить отдельно.
Подготовьте выборку и отметку отправки
Начните с JQL в обычном поиске Jira. Например, project = OPS AND resolution IS EMPTY AND duedate < startOfDay() выбирает нерешённые задачи проекта с датой до сегодняшнего дня. OPS здесь демонстрационный ключ: замените его своим. Сверьте результаты с реальными статусами проекта, потому что незаполненная Resolution в завершённой задаче бывает ошибкой workflow. Добавьте исключения для согласованных пауз и ожидания заказчика, если это соответствует процессу. Не используйте общий запрос по всему сайту ради удобства.
Создайте поле даты последнего напоминания либо иной явно выделенный признак. Оно должно хранить состояние этого процесса, а не переиспользовать поле бизнес-срока. Опишите, кто вправе его исправлять. Если используется дата, проверка перед отправкой должна учитывать отсутствие значения и истечение выбранного периода. На пилоте подготовьте задачи с пустой отметкой, сегодняшней отметкой и отметкой прошлой недели.
Соберите правило по небольшим шагам
Выберите Scheduled trigger с JQL, затем добавьте условия проекта и актуального состояния. Сначала вместо отправки используйте Log action: записывайте ключ задачи и решение, требуется ли напоминание. После проверки добавьте выбранное уведомление и изменение отметки отправки. Размещайте изменение отметки после действия уведомления, чтобы явная ошибка отправки не выглядела как успешно выполненное напоминание. Это порядок компонентов, а не гарантия единой транзакции между Jira и внешней почтой.
Текст сообщения должен содержать ссылку на задачу, исходный срок и конкретное ожидаемое действие: обновить план либо объяснить блокировку. Не копируйте описание обращения в письмо, если там могут быть персональные данные. Для задачи без исполнителя предусмотрите отдельный согласованный адресат или оставьте её в отчёте для координатора. Пустой адресат не должен превращаться в тихо пропущенное напоминание.
Проверьте повторные запуски и сбои
Выполните правило на небольшой тестовой группе дважды. В первый раз подходящие задачи получают сообщение, во второй новые сообщения не появляются. Отдельно измените срок на будущий, завершите задачу, снимите исполнителя и заполните отметку вручную. Для каждого случая заранее запишите ожидаемый результат. Убедитесь, что технический пользователь правила имеет доступ к полю и задачам, но не получает лишние административные права ради обхода одной ошибки.
Между уведомлением и записью отметки возможен частичный сбой. Поэтому простая отметка обеспечивает практическую защиту от повторов, но не строгую доставку ровно один раз. При разборе инцидента сначала сверяйте историю задачи и журнал выполнения, затем исправляйте отметку. Массовое обнуление поля без проверки приводит к повторной рассылке всем адресатам.
Масштабирование, наблюдение и откат
После пилота посчитайте, сколько задач обрабатывается за запуск, сколько уведомлений действительно полезно и сколько задач не имеет адресата. Проверяйте ограничения Automation в актуальной документации, вместо того чтобы считать любой JQL неограниченным. Если выборка выросла, разделите её по проектам или ответственным областям и уменьшите частоту до разумной для процесса. Для особо больших разовых исправлений рассмотрите контролируемую массовую операцию, а не постоянно работающее правило.
Для отката отключите расписание и сохраните журнал последних запусков. Не удаляйте полезные комментарии автоматически: сначала согласуйте, что является ошибочным сообщением. Поле отметки можно оставить для расследования, затем архивировать его назначение в документации. Критерий успешного внедрения — сокращение забытых задач при предсказуемом числе уведомлений, а не максимально частое выполнение автоматизации.
Контрольный пример для владельца процесса
Перед передачей правила поддержке проведите короткую демонстрацию на трёх задачах. Первая просрочена и получает одно сообщение. У второй срок ещё не наступил, поэтому она остаётся без изменений. У третьей напоминание уже отправлено в текущем периоде, и повторный запуск её пропускает. Затем намеренно уберите исполнителя у первой задачи и покажите согласованную обработку исключения. В инструкции сохраните ожидаемые результаты, адресата ошибки и место отметки отправки. Это позволит новому сопровождающему проверить работоспособность без массовой рассылки и без знания внутренних деталей первоначальной настройки.
Официальная документация
Применить это к вашей системе
Обсудим контекст, ограничения и безопасный порядок изменений.
Обсудить задачу