Применимость: Cloud. Названия пунктов и доступность функций зависят от версии, плана и типа проекта. Проверяйте изменения на тестовом окружении. Описанные рабочие процедуры — предлагаемый подход, а не гарантии поставщика.
Задача и границы диагностики
Клиент видит новый ответ на портале, но письма нет. Прежде чем менять почтовый домен или включать все уведомления, нужно определить, на каком участке остановилась цепочка: событие, выбор адресата, подписка, отправка или обработка у получателя. Разберём учебный сценарий для Jira Service Management Cloud: агент отвечает на тестовое обращение, а отдельный клиентский аккаунт проверяет портал и свой почтовый ящик. Это инструкция с ожидаемыми результатами, а не отчёт о выполненном тесте.
Материал относится к облачной версии без фиксированного номера релиза. В интерфейсе Atlassian встречаются названия Project settings и Space settings; ориентируйтесь на раздел Notifications и тип уведомлений Customer notifications. Для Data Center нужны документация установленной версии, собственная почтовая конфигурация и другие журналы. Серверные пути логов из инструкций Data Center здесь не применяются.
Успех проверки — объяснённая причина отсутствия конкретного письма и воспроизводимый контрольный сценарий. Открывающаяся заявка подтверждает доступ к содержимому, но сама по себе не доказывает отправку уведомления или доставку во входящие.
Подготовьте изолированный пилот
Выберите отдельный сервисный проект для испытаний и создайте через его портал заявку с безобидной темой «Проверка ответа поддержки». Запишите её ключ, например MAIL-1, выбранный Request type и клиентский аккаунт Reporter. Возьмите двух разных участников: агент отвечает, клиент читает. Один аккаунт в обеих ролях затрудняет интерпретацию уведомлений о собственных действиях и приоритета внутренних сообщений.
Понадобятся администратор проекта для просмотра настроек уведомлений, агент для ответа и владелец тестового ящика. Не используйте реальных клиентов, массовое добавление участников или организацию с общими обращениями. Предварительно запишите исходное состояние выбранного шаблона: включение, адресаты и содержание. Если настройку нельзя посмотреть с текущими правами, попросите администратора показать её вместо выдачи широкого административного доступа.
Заведите внутренний протокол с ключом заявки, действием, временем и часовым поясом, ожидаемым адресатом и наблюдаемым результатом. Используйте уникальные маркеры PUBLIC-A и INTERNAL-B. Это позволит отличить письмо о создании обращения от письма об ответе и не принять старую переписку за новый результат.
Проверьте адресата и действительный Request type
В карточке убедитесь, что обращение находится в Jira Service Management и поле Request type заполнено допустимым значением. Обычная задача, созданная вне сервисного запроса или без типа запроса, не является надёжной базой для проверки customer notifications. Для первого прогона удобнее новая заявка через портал, чем исправление старой задачи со сложной историей переноса.
Проверьте Reporter и точный адрес аккаунта, затем войдите этим клиентом в портал и откройте MAIL-1. Если нужен второй получатель, добавляйте его именно как Request participant с учётом политики совместного доступа. Участники обращения следуют ограничениям безопасности задачи: наличие имени в поле не даёт безусловного доступа. Не ослабляйте безопасность всей схемы ради одного письма.
Watchers и Request participants решают разные задачи. Настройки внутренних уведомлений нельзя считать заменой клиентским. Особенно внимательно проверяйте аккаунты, совмещающие роль агента, исполнителя, наблюдателя и клиента: для агентов и администраторов внутренние уведомления могут иметь приоритет. Для чистого пилота оставьте клиенту только необходимую роль заявителя и не добавляйте его в наблюдатели.
Сверьте событие, адресатов и подписку
Откройте Notifications → Customer notifications и найдите уведомление о добавлении публичного комментария, обычно Public comment added. Запишите, включено ли оно и кого содержит поле To. Не переключайте одновременно несколько шаблонов. Письмо о создании заявки, письмо об участии и письмо о публичном ответе — разные события; работоспособность одного ничего не гарантирует для другого.
В портале посмотрите состояние подписки именно на MAIL-1. Отписка от отдельного обращения отличается от блокировки адреса после возвратов почты. При этом правила зависят и от выбранного типа получателя: документация отдельно описывает Reporter (customer) и Customers involved. Нельзя обещать, что выключатель Notifications off блокирует абсолютно все сообщения, включая разрешение заявки и запрос согласования.
Для базовой проверки не требуется менять оформление письма. Редактирование шаблонов ограничено тарифом и условиями пробного периода; недоступная кнопка не доказывает неисправность доставки. Если настройки уже соответствуют сценарию, переходите к воспроизведению. Когда включены safe customer notifications, скрытое содержимое письма тоже не следует путать с отсутствием отправки.
Выполните положительную и отрицательную проверку
Из аккаунта агента добавьте публичный ответ с маркером PUBLIC-A. До сохранения ещё раз проверьте режим ответа: внутреннюю заметку легко принять за комментарий клиенту. После сохранения откройте заявку клиентским аккаунтом, найдите маркер и отдельно проверьте почтовый ящик, включая спам и карантин. Зафиксируйте оба наблюдения: видимость в портале и наличие письма.
Затем агент добавляет внутреннюю заметку INTERNAL-B без конфиденциальных данных. Ожидаемый отрицательный результат для клиентского аккаунта: содержимое заметки не видно на портале и клиентское уведомление с этим текстом не поступает. Внутренние сообщения другим сотрудникам оцениваются отдельно и не означают провал этого теста. Если заметка оказалась публичной, остановите проверку и исправьте процедуру ввода.
Не нажимайте повторную отправку многократно из-за задержки. Сначала сверьте ключ, время, маркер и журналы. Для повторного контролируемого прогона используйте новый маркер PUBLIC-C и отметьте, какая единственная настройка изменилась. Не устанавливайте произвольный универсальный срок доставки: сравнивайте наблюдения с состоянием сервиса и данными почтового администратора.
Читайте журналы без ложного вывода об успехе
В актуальном интерфейсе откройте Email logs в боковой панели сервисного проекта. Эта точка входа заменяет Customer notification logs. Для исходящих уведомлений выберите Customer notifications и Request notifications, затем сопоставьте ключ MAIL-1, получателя, имя уведомления и время. Входящий канал Incoming emails отвечает на другой вопрос: как письмо превратилось в заявку.
Документация указывает, что журнал клиентских уведомлений хранит неуспешные события, а успешная доставка в нём не сохраняется; срок хранения данных составляет 21 день. Поэтому пустой результат поиска не доказывает доставку. Сохраняйте подтверждение из тестового ящика и при необходимости данные почтового администратора. Не откладывайте разбор до истечения окна хранения.
В деталях ошибки могут быть неверный адрес, ограничение отправки, слишком большой шаблон, блокировка адреса или отказ провайдера. Исправляйте причину, соответствующую записи. Если адрес заблокирован из-за возвратов, сначала устраните проблему с ящиком. Unblock email address разрешает будущие уведомления и не пересылает старые автоматически. Повторную проверку проводите новым безопасным событием.
Разделите ошибки конфигурации и почтовой доставки
Если публичный ответ не виден клиенту, вернитесь к режиму комментария, доступу и роли участника. Если ответ виден, но адресат не подходит под настройки события, разбирайте шаблон и подписку. Если журнал сообщает об отказе почтового провайдера, передайте почтовому администратору время, отправителя, тестового получателя и описание ошибки по внутреннему защищённому каналу.
Не меняйте DNS, глобальную схему уведомлений и содержимое всех шаблонов одним действием. Такой ремонт стирает диагностические различия и может расширить аудиторию рассылки. Ограничение отправки также не лечится добавлением ещё одного правила Automation: оно создаёт дополнительный канал сообщений и способно увеличить число дублей.
При повторяемой внутренней ошибке подготовьте обращение в Atlassian Support: Cloud-сайт, сервисный проект, ключ безопасной тестовой заявки, название события, часовой пояс и последовательность действий. Уберите персональные данные и секреты из снимков. В итоговом протоколе различайте ожидаемый результат, реально полученное письмо и гипотезу, которую ещё предстоит проверить.
Откат и критерии завершения
Если меняли адресатов или включение уведомления, восстановите записанные исходные значения и сохраните настройку. Удалите добавленного только для пилота участника и проверьте доступ повторно. Изменения текста шаблона возвращайте по сохранённой исходной версии. Если настройку не меняли, не делайте формальный откат всей конфигурации проекта.
Уже отправленное письмо нельзя вернуть выключением шаблона. Удаление тестового комментария также не отзывает сообщение из чужого ящика. Поэтому пилот содержит только безобидные маркеры, а тестовый запрос закрывается по вашей внутренней процедуре. Не удаляйте историю реального клиентского обращения ради чистого журнала.
Завершайте диагностику, когда положительный и отрицательный сценарии проверены разными аккаунтами, причина исходной проблемы подтверждена наблюдениями, а временные настройки возвращены или отдельно согласованы для постоянного использования. Если письмо всё ещё отсутствует, оставьте конкретный следующий шаг и владельца проверки. Запись «ошибок в журнале нет» недостаточна для заключения о восстановленной доставке.
Официальная документация
- Atlassian: View email logs
- Atlassian: Customer notification logs
- Atlassian: Customer and internal notifications
- Atlassian: Fix Cloud customer notification issues
- Atlassian: Edit customer notifications
- Atlassian: Request participants
- Atlassian: Watchers and participants
- Atlassian: Notification best practices
Применить это к вашей системе
Обсудим контекст, ограничения и безопасный порядок изменений.
Обсудить задачу