Инспекции в Field Service: как они работают и как их правильно настраивать

В последние недели мы активно работали с функциональностью инспекций в Field Service. Инспекции становятся всё более востребованным инструментом — они позволяют структурировать процесс проверки оборудования, автоматически учитывать длительность работ и обеспечивать инженерам удобный интерфейс для заполнения данных в мобильном приложении.

В этой статье разберём, как создаётся инспекция, как настроить её логику, как привязать её к Work Order через Service Tasks и как она отображается на мобильных устройствах.

А узнать больше можно в нашем видео: 

Создание инспекции

Инспекция строится из набора полей разных типов: текстовых, списков, переключателей и др.

Процесс начинается с создания нового шаблона (Inspection Template). Список доступных полей достаточно широкий, поэтому можно гибко настраивать опросник под конкретный сценарий — от базовой проверки оборудования до сложных технических процедур.

Пример базового набора полей:

• Model — выпадающий список с опциями. Можно отметить поле как required.

• Serial Number — текстовое поле.

• Дополнительные dropdown‑поля, которые можно наполнять вручную или с подсказками системы.

При добавлении новой опции система автоматически пытается предугадать значение — это ускоряет заполнение списка.

Все данные инспекции сохраняются в системе в закодированном JSON‑формате: сначала URL‑кодирование, потом Base64. Благодаря этому инспекции занимают минимальный объём, быстро загружаются и практически не влияют на производительность.

Логика отображения и превью

После наполнения опросника можно открыть Preview, чтобы увидеть, как инспекция будет выглядеть для инженера.

Здесь же доступна логика отображения — Show/Hide. Например:

• пока значение ControlBox = Standard — отображается пункт №12;

• при выборе Standard+ — пункт скрывается.
  

В полной версии системы подобная логика реализуется бизнес‑правилами (Business Rules), но для инспекций она работает быстрее и гибче.

Также в инспекциях доступен функционал переводов, что важно для международных проектов.

Публикация и создание Service Task

Перед использованием инспекцию необходимо опубликовать. После публикации доступны два варианта:

1. Создать Service Task вручную.

2. Автоматически сгенерировать сервисный таск при публикации.

Service Task обычно включает:

• порядок выполнения (Sequence),

• длительность (Duration),

• связь с инспекцией.

Использование инспекции в Work Order

После настройки тасков, при создании Work Order достаточно указать соответствующий Incident Type.

Система автоматически:

• подхватывает все связанные сервисные таски,

• учитывает их длительность,

• рассчитывает итоговое время букинга.

Пример: Если инспекция занимает 1 час и других задач нет — система автоматически устанавливает длительность Work Order на 1 час.

Чтобы Work Order стал видим инженеру в мобильном приложении, нужно изменить его статус на Schedule Confirmed.

Мобильное приложение: как инженер видит инспекцию

В мобильном приложении инспекция отображается в отдельной форме. Она загружается быстрее стандартного WorkOrderForm и содержит только необходимые поля.

Доступные функции:

• заполнение вопросов опросника,

• логика Show/Hide работает в реальном времени,

• возможность вводить текстовые ответы,

• прогресс выполнения (Completion %),

• фиксация результата,

• добавление заметок и работа с таймлайном.

Интерфейс оптимизирован именно для инспекций: если обычные таски можно закрывать «галочками», то инспекции требуют ручного заполнения — и мобильная форма идеально подходит под такой сценарий.

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

Заключение

Инспекции в Field Service — это удобный и эффективный инструмент для структурированной проверки оборудования и сбора данных на месте. Они легко настраиваются, практически не занимают места, поддерживают динамическую логику и хорошо интегрируются с Work Order и мобильным приложением.

Мы рассмотрели:

• как создать инспекцию,

• как настроить логику и переводы,

• как привязать её к Incident Type через Service Tasks,

• как она отображается инженеру в мобильном приложении.
  

Решение прекрасно подходит для кейсов, где требуется чёткий процесс проверки и фиксации результатов.