Вернуться к статьям Этот режим полезен до подключения робота к стадии. Он помогает найти неверные условия, потерянные значения и несогласованные выходы. Реальные права сотрудника и фактический результат записи в Битрикс24 проверяются отдельным реальным запуском.
Проверка схемы и моделирование отвечают на разные вопросы
Кнопка «Проверить схему» проверяет структуру, связи, привязки и объявленные типы. Она помогает обнаружить, например, ошибку передачи значения или неполную настройку. Успешная структурная проверка не означает, что все бизнес-правила выбраны правильно.
Кнопка «Моделировать» рассчитывает текущую схему с подготовленными входами. Здесь можно увидеть, какая ветвь выполнится и что вернёт результат. Если автор сам задал ответ «контакт найден», успешная модель подтверждает обработку этого ответа. Она не доказывает, что поиск найдёт такой контакт на портале.
Поэтому перед началом запишите ожидаемый результат каждого теста. Проверка «схема завершилась» слишком слабая: робот может успешно вернуть чужой ID контакта или неверный признак создания.
Перед каждым тестом задайте ожидаемый результат. После изменения схемы или входов повторите проверку.
Подготовьте набор проверок на примере контакта для лида
Для учебной контактной схемы нужны положительный тестовый lead_id, при необходимости responsible_id и имитации ответов внешних блоков. Числа здесь служат синтетическими значениями. Присутствие в модели ID реальной записи не заставляет приложение прочитать её из CRM.
| Проверка | Ответ поиска | Что должно произойти |
|---|---|---|
| Контакт существует | Найден, возвращён его ID | Создание пропущено, ID передан на привязку. |
| Контакт отсутствует | Не найден | Выполнена ветвь создания, возвращён новый ID. |
| Перед созданием контакт уже появился | Сначала не найден; создание возвращает существующий | Привязан возвращённый контакт, признак создания ложный. |
| Ответ блока неправильного типа | Вместо «Да/нет» передана строка | Нет успешного результата по неверным данным. |
Такой набор проверяет логику разных путей. Он не моделирует конкурентные записи других сотрудников и не доказывает глобальную уникальность контактов.
Во входах модели заданы lead_id=7 и responsible_id=1. Это учебные значения; существование записей и реальные права CRM на этом шаге не проверяются.
Отдельный набор ответов: после отрицательного поиска блок создания возвращает ID 501 и created=false. Это проверка маршрута на имитациях.
Как задать ответы внешних блоков
Откройте «2. Проверить» → «Проверка и моделирование». Выполните проверку схемы и задайте входы. В разделе «Данные для имитации портальных блоков» используйте пути, перечисленные в панели вашей схемы. Не переносите пути из другого сценария без сверки.
Ответ включает port: "success" и объект outputs. Для блока поиска требуются found, contact_id, match_count; для создания контакта нужны contact_id и created; для привязки нужен contact_id. Конкретные поля соответствуют контактному примеру, а не любому внешнему блоку приложения.
В JSON логические значения записываются как true и false. Строка "false" содержит текст и не равна логическому значению false. Если контакт отсутствует, используйте found: false, contact_id: null, match_count: 0.
Согласуйте данные внутри одной ветви. Если создание вернуло ID 501, слияние ветвей и привязка должны передать тот же контакт. Можно подготовить модель с несогласованными числами и получить формально допустимые данные, которые не отвечают задаче. Именно поэтому результат надо сравнивать с ожидаемым значением.
В модели намеренно не задан ответ блока привязки: получена MOCK_FIXTURE_REQUIRED. Это отсутствие учебной имитации, а не отказ CRM, недостаток прав или частично созданная запись.
Как читать итог моделирования
После нажатия «Моделировать» проверьте итоговые выходы и выполненные шаги. В варианте найденного контакта создание должно быть пропущено. В варианте создания проверьте ID и created=true. Если блок создания вернул существующий контакт, ожидается created=false.
Не трактуйте ложный признак создания как ошибку всего сценария. Он означает, что новый контакт не потребовался. Успех определяется завершением нужного пути и получением корректного общего результата.
После правки схемы или входов прежний расчёт может получить отметку «Устарело». Повторите проверку для текущего варианта. Скриншот удачной модели, сделанный до изменения условия, не подтверждает новую логику.
Синтетический найденный контакт: модель завершилась, вернула ID 501 и created=false. Итог нужно читать вместе с заданными ответами внешних блоков.
Чего моделирование не проверяет
Модель не подтверждает, что исполнитель видит лид и контакт, имеет право создавать запись, а обязательные поля портала заполнены. Она также не проверяет настоящую регистрацию робота, входы шага на стадии и использование результата следующим роботом.
Для реальной проверки создайте версию и используйте отдельную тестовую карточку с понятными данными. Настоящий запуск может изменить CRM. После него нужны журнал, проверка карточки и конечное действие следующего шага. Если запись завершилась с неизвестным исходом, не повторяйте её до проверки фактических данных.
Частые вопросы
Можно моделировать, если контакта ещё нет на портале?
Да. Ответ блока создания задаётся синтетически, поэтому настоящая карточка для моделирования не нужна. Ветвь можно проверить до реальных записей.
Моделирование заменяет тестирование на стадии?
Нет. Оно проверяет расчёт схемы на заданных данных. Настройка стадии, права и изменения CRM требуют самостоятельной проверки.
Дополнительные инструкции
Подробные поля контактного примера приведены в руководстве «Получить или создать контакт для лида». Оно предназначено для порталов с лидами; на Базовом тарифе лидов нет.