Forms в JSM Cloud: связываем ответы с полями Jira и JQL

Задача: ответ виден агенту, но отсутствует в поиске

Клиент выбрал сервис в красивой форме, агент прочитал ответ, а очередь по этому сервису осталась пустой. Сначала выясните, где хранится значение. Вопрос Forms и одноимённое пользовательское поле Jira — разные элементы. Совпадение подписей не создаёт между ними связь. Для обычного JQL по полю Jira нужен ответ именно в этом поле, а не только внутри прикреплённой формы.

Разберём учебный пилот: запрос «Диагностика сервиса», варианты VPN и Почта, одно связанное поле для маршрутизации и дополнительный вопрос «Что наблюдаете?», который останется только в Forms. Цель — подтвердить путь данных от портала до поиска, прежде чем подключать назначения или уведомления. Здесь нет выполненных испытаний на клиентском сайте: ниже приведены настройка и ожидаемые проверки.

Процедура относится к встроенным Forms в Jira Service Management Cloud и company-managed сервисному проекту. Cloud обновляется без устанавливаемого номера релиза; ориентируйтесь на доступный интерфейс и документацию. В новых меню встречаются Space settings и work item, в прежних — Project settings и issue. Для Data Center и ProForma нужна отдельная инструкция установленной версии. Формы Jira другого продукта и расширения Marketplace сюда не входят.

Подготовьте поле и безопасный участок пилота

Нужны администратор сервисного проекта, агент для проверки результата и тестовый клиент портала. Администратор Jira заранее подготавливает поле «Сервис пилота» типа Select list (single choice), с вариантами VPN и Почта и контекстом, применимым к пилотному проекту и типу задачи. Запишите его фактический ID. Число 12345 ниже — заменяемый пример, а не универсальный идентификатор.

Используйте отдельный учебный тип запроса и нейтральные сведения. Не меняйте обязательность общего поля и не подключайте рабочие правила назначения ради первого опыта. До изменения сохраните описание текущей формы запроса, связи полей, настройки Forms и JQL очереди. Если существующее поле уже используется другими командами, согласуйте его применение; отдельное поле пилота проще убрать из процесса без воздействия на соседние запросы.

Сформулируйте ожидаемую выборку: заявка с VPN должна находиться в запросе для VPN, заявка с Почтой — не должна. Для контроля подготовьте также запрос без значения сервиса. В пилоте оставим вопрос необязательным, чтобы проверить этот случай отдельно. Остальные обязательные поля создания заявки должны заполняться обычным способом.

Соберите небольшую форму

Откройте Space settings → Request management → Forms и создайте пустую форму «Диагностика сервиса — пилот». Добавьте вопрос с одиночным выбором «Сервис» и необязательное текстовое поле «Что наблюдаете?». Начните с одного обычного раздела: условное отображение пока не требуется. Не просите пароли, токены или содержимое клиентских запросов.

Через Preview проверьте подписи, доступные значения и понятность инструкции. Попросите тестового участника объяснить, какой вариант он выберет для проблемы с подключением VPN. Эта проверка касается удобства вопроса; появление ответа в предпросмотре ещё не подтверждает запись в Jira. Сохраните форму через Save changes.

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

Установите связь и устраните двойной ввод

Выберите вопрос «Сервис». В его панели Linked Jira field укажите подготовленное поле «Сервис пилота». Типы должны быть совместимы: одиночный выбор связывается с подходящим полем выбора, а не с текстом. Проверьте наличие VPN и Почты в связанном списке и сохраните изменения. Если нужного поля нет, остановитесь и проверьте тип и применимость с администратором.

Один Jira field связывается только с одним вопросом в пределах формы. Не создавайте второй вопрос «Сервис для отчёта» с той же связью. Поле Jira также не должно одновременно запрашиваться отдельным элементом request form и связанным вопросом Forms. При связывании уже добавленное поле может быть убрано из обычной формы запроса; проверьте итоговый экран клиента.

Вопрос «Что наблюдаете?» оставьте без связи: в этом пилоте он нужен агенту как пояснение, а не как ключ маршрутизации. Запишите таблицу соответствий в инструкции команды: вопрос «Сервис» → поле Jira с фактическим ID; пояснение → данные Forms. Такая запись помогает отличить смену подписи от смены места хранения.

Подключите форму к одному типу запроса

В настройках нужного Request type выберите Attach form и подключите подготовленную форму. Альтернативный путь — Settings в конструкторе Forms, переключатель Attach to request types и выбор учебного типа запроса. Используйте один из путей и сохраните настройки; повторно прикреплять форму через второй путь не нужно.

Откройте полный предпросмотр запроса в портале. Проверьте, что вопрос сервиса встречается один раз, Summary и остальные обязательные данные доступны, а нейтральная инструкция понятна клиенту. Затем создайте новую контрольную заявку именно через портал. Наличие шаблона в списке Forms само по себе не означает, что он подключён к нужному типу запроса.

Этот сценарий не покрывает создание через email, чат, виртуального агента или виджет: Forms сейчас недоступны в этих каналах. Для обращений из других каналов отдельно определите способ заполнения Jira field и работу с пустым значением. Не делайте поле глобально обязательным, пока не проверены все способы поступления заявок.

Проверьте поле Jira до настройки очереди

В новой заявке откройте Forms и убедитесь, что ответ сохранён. Затем агент проверяет само поле «Сервис пилота» в задаче. После этого выполните JQL ниже под тем же пользователем, которому нужна очередь. Замените FORMPILOT ключом своего проекта, а 12345 — ID подготовленного поля. Запрос с равенством рассчитан на одиночный список, не на текстовое поле.

Сначала проверяйте каждую заявку по известному ключу и значению поля, затем общую выборку. Если заявку видит администратор, но не агент, проверяйте доступ к ней отдельно от связи Forms. Ошибка имени или ID поля требует исправления запроса; пустая выборка сама по себе не показывает, на каком этапе потерялось значение.

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

project = FORMPILOT AND cf[12345] = "VPN"

project = FORMPILOT AND cf[12345] IS EMPTY

Контрольная матрица и повторное редактирование

Приведённые ниже пункты — план проверки. Для каждого сохраните ключ заявки, выбранный ответ, фактическое значение Jira field и результат JQL. Не отмечайте проверку успешной только по виду портала. После исправления шаблона создавайте новые контрольные заявки: изменение конструктора не обновляет уже существующие экземпляры формы.

Отдельно проверьте форму, открытую для редактирования на существующей заявке. Связанные поля синхронизируются в обе стороны; в таком состоянии изменение ответа может обновить Jira field ещё до повторной отправки формы. Поэтому отправка формы не должна автоматически считаться единственной границей изменения бизнес-данных. Перед использованием значения в процессе определите допустимые состояния и проверьте их на пилоте.

• Выбор VPN: ответ и поле Jira согласованы, заявка входит в выборку VPN.
• Выбор Почта: поле содержит Почта, заявка не входит в выборку VPN.
• Пустой необязательный сервис: заявка попадает в проверку IS EMPTY и остаётся доступной первой линии.
• Открытая форма на существующей заявке: после изменения связанного ответа проверены поле Jira и результат поиска.
• Изменение поля Jira агентом: проверено соответствующее значение в связанной форме с учётом её состояния.
• Обычный агент и клиент портала: проверены разрешённая видимость и отсутствие двойного вопроса.

Ошибки, ограничения видимости и откат

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

Ограничение просмотра самой формы не скрывает связанные Jira fields и вложения, включая PDF-копии. Для чувствительных данных отдельно проверяйте доступ к задаче и к каждому месту хранения. В пилоте используйте только нейтральные ответы; скрытый раздел или замок на форме не являются доказательством защиты значения, переданного в общее поле Jira.

Для отката отключите пилотную очередь и зависимые правила, снимите подключение формы с учебного типа запроса и восстановите прежнюю конфигурацию request form по сохранённому описанию. Сохраните созданные контрольные заявки и значения для сверки. Отсоединение формы не является обещанием удалить уже записанные данные или отменить действия правил.

Не удаляйте общее поле Jira и не очищайте существующие ответы массово. Если пилот изменил значения в задачах, возвращайте их отдельно по зафиксированным исходным данным и с владельцем процесса. После возврата создайте новую заявку прежним способом и проверьте обязательные поля и доступность для агента. Расширяйте настройку только когда путь «ответ → поле → поиск» объясним для каждого контрольного случая.