Обязательные поля в Битрикс24: как связать стадии и роботов с готовностью сделки
Заполненное поле не всегда означает, что заказ готов к исполнению. Разбираем, когда требовать данные, как проверить их смысл и как не запустить внешнее действие раньше времени.
В сделке есть адрес доставки и сумма, поэтому менеджер переводит её в работу. Робот отправляет задание исполнителю. Позже выясняется, что в адресе написано «уточняется», а сумма относится к предыдущей редакции предложения. Формально обязательные поля заполнены, но нужного подтверждения нет.
Настройка обязательных полей полезна, когда каждый переход опирается на конкретный результат. Разберём предлагаемую схему для заказа с согласованием состава и передачей в исполнение. Стадии и названия полей ниже — учебный пример, который нужно адаптировать к вашему процессу.
Стадия «Квалификация» может означать, что известны задача клиента и следующий контакт. «Предложение согласовано» — что клиент подтвердил конкретную редакцию условий. «Передано в исполнение» — что исполнитель получил согласованный состав и принял работу. Это разные факты, которым нужны разные данные.
Не требуйте все сведения при первом звонке. Менеджер ещё не знает точного адреса и комплектации, поэтому заполняет обязательные поля заглушками. Позже такие значения сложно отличить от настоящих. Лучше требовать информацию на этапе, где она уже должна быть получена и действительно влияет на решение.
Для каждого обязательного реквизита укажите владельца, допустимое значение и способ проверки. Например, «адрес доставки» должен относиться к текущему заказу, а «версия предложения» — к подтверждённому файлу или записи. Наличие непустой строки не проверяет ни одну из этих связей.
В официальной инструкции Битрикс24 описана обязательность полей для карточек и отдельных стадий. Доступность функции зависит от тарифа. Для сделок и смарт-процессов настройку нужно проверять отдельно по воронкам, а не считать её общей для всего портала.
Откройте нужную сделку, настройки поля и выберите стадии, на которых значение требуется. Затем проверьте карточку под пользователем, который действительно переводит сделку. Администратор настраивает механизм, но рабочее заполнение должен выполнить менеджер со своими правами и видом карточки.
Если поле обязательно, сотрудник должен понимать, где взять значение и как исправить ошибку. Текст подсказки «заполнить корректно» не помогает. Полезнее указать предмет: номер подтверждённого предложения, согласованная дата или адрес конкретной точки разгрузки.
Этап учебного заказа
Что требуется
Что нельзя считать подтверждением
Уточнение задачи
Предмет заказа и следующий шаг
Любая непустая заметка
Согласование
Редакция условий и результат ответа
Просто приложенный старый файл
Передача
Состав, адрес, исполнитель
Перетаскивание карточки
Завершение
Факт исполнения и основание
Только отсутствие открытых дел
Таблица задаёт смысл проверок. Она не означает, что все эти условия автоматически обеспечиваются одним штатным обязательным полем.
В предлагаемом процессе сначала проверяются условия готовности, затем фиксируется принятое состояние и только после этого создаётся задание или отправляется сообщение. Если часть сведений поступает из внешней системы, нужно дождаться подтверждённого переноса, а не только входа карточки на стадию.
В документации об условиях роботов описаны независимый запуск и запуск после предыдущего робота. Порядок важен, если один робот готовит данные для другого. Два независимых действия не следует считать последовательностью только потому, что их расположили друг под другом.
Для значимого внешнего действия определите отдельный признак результата. Например, у передачи в исполнение должны появиться ID задания и время принятия либо понятная ошибка. Один флажок «отправлено» до подтверждения внешней системы не доказывает, что исполнитель получил работу.
При ошибке оставляйте карточку в состоянии, из которого можно продолжить процесс. Менеджеру нужны причина и следующее действие: исправить адрес, уточнить исполнителя или повторить техническую отправку. Повтор всей цепочки после каждого сбоя создаёт риск второго задания и повторного сообщения клиенту.
Проверка ручного перехода через интерфейс подтверждает только этот маршрут. Сайт, импорт, приложение и ваш REST-обработчик могут заполнять данные другими способами. Их поведение нужно испытать на том же наборе правил. Не стоит заранее объявлять обязательность интерфейса универсальным барьером для любого канала.
В собственной интеграции валидируйте необходимый набор полей перед внешним действием. Если пришёл неполный заказ, сохраните его как требующий уточнения и назначьте владельца разбора. Потеря обращения из-за отсутствующего второстепенного поля хуже, чем явная очередь незавершённых заявок.
Проверьте также изменение данных после согласования. Если адрес или состав заказа изменились, прежняя готовность может стать недействительной. В проектной схеме подтверждение связывают с конкретной редакцией условий. Исправление телефона не обязательно требует повторного согласования цены; изменение комплектации — может требовать. Существенные поля определяют по процессу.
Возврат сделки назад не должен молча отправлять прежнее задание второй раз. Для каждого действия решите, что происходит при повторном входе: уведомление можно повторить по правилу, существующее задание — открыть, изменение состава — оформить новой редакцией.
Если исполнитель уже начал работу, простого исправления полей недостаточно. Нужен маршрут изменения заказа: кто подтверждает новые условия, что приостанавливается и как исполнитель узнаёт о замене. Стадия показывает состояние, но не отменяет уже отправленный документ или поручение.
Для собственного обработчика полезно хранить связь задания со сделкой и редакцией. Если связь есть, технический повтор должен проверить результат, а не создать новую копию. Конкретный способ защиты зависит от используемого инструмента; отдельное поле без проверки конкурирующих запусков не является полной гарантией.
Попробуйте переход с пустым полем, заглушкой, корректным значением и изменённой редакцией. Повторите сценарий вручную и через используемую интеграцию. Затем вызовите ошибку внешнего сервиса, восстановите доступ и проверьте, что продолжился только невыполненный шаг.
Отдельно проверьте возврат на предыдущую стадию и повторную передачу. В карточке должны остаться понятные основания готовности, актуальная редакция и одна согласованная связь с результатом. Внешний исполнитель должен получить те же данные, которые подтвердил менеджер.
Достаточно ли сделать больше полей обязательными? #
Нет. Избыточная обязательность часто создаёт формально заполненные, но бесполезные значения. Добавляйте поле, когда можете назвать решение, которое без него нельзя принять, и источник достоверного значения.
Когда нужен бизнес-процесс вместо нескольких роботов? #
Когда требуется самостоятельный маршрут согласования, несколько участников, разбор отказов или управление редакциями. Для простого напоминания может быть достаточно робота. Выбор определяется связями действий и критериями завершения.
NetLabCS поможет связать стадии, проверку данных и внешние действия при разработке бизнес-процессов в Битрикс24 . Для обсуждения процесса выберите переход, после которого сейчас возникают ошибки, и подготовьте пример корректного и неполного заказа.
