Как проверить данные лида перед дальнейшей автоматизацией в Битрикс24

Робот вернёт ready=true, если один из входов непустой, и ready=false, если оба пусты. Он не блокирует переход стадии автоматически и не определяет, существуют ли телефон и почтовый ящик. Это отдельное правило вашей автоматизации, а не готовый встроенный шаблон проверки лидов.

Сначала договоритесь о смысле готовности

У разных компаний обязательные данные различаются. Одной нужен телефон для звонка, другой достаточно email для ответа, третьей требуются реквизиты и согласие на обработку данных.

Для учебного примера выберем узкое правило: у лида есть хотя бы один переданный канал связи. Оно отвечает только на вопрос о заполнении. Корректность номера, доступность клиента и право отправлять сообщение остаются за пределами проверки.

Если процесс требует именно телефон, не копируйте правило «телефон или email». Сначала измените условие приёмки, затем схему.

Какие входы и выходы нужны

Откройте «Параметры робота» и объявите текстовые входы phone и email. В моделировании им можно явно передать пустую строку. Если сделать поле обязательным и запретить пустой ввод на уровне формы, сценарий может не дойти до проверки пустоты: это нужно учитывать при настройке.

Для результатов подготовьте два выхода:

Например, успешная проверка вернёт «Канал связи указан», а отрицательная «Нет телефона и email». Сообщение помогает менеджеру понять причину. Стабильный логический признак удобнее для условий следующего робота, чем сравнение длинной фразы.

Учебная схема работает с переданными значениями. Она сама не читает карточку по ID лида. При подключении сопоставьте параметры с нужными данными CRM и проверьте, в каком виде поступают многозначные поля. Текстовый вход не следует автоматически считать всем списком телефонов карточки.

Как построить проверку

Схема использует два последовательных вопроса:

1. Телефон пуст?
2. Если телефон пуст, пуст ли email?

При непустом телефоне переходите к результату «готов». При пустом телефоне проверяйте email. Непустой email тоже ведёт к результату «готов», а два пустых значения к результату «не готов».

Для каждого условия берите первое значение из соответствующего параметра и выбирайте проверку пустоты. После ветвей можно использовать «Слияние ветвей», чтобы привести ready и reason к общим выходам. Следующий шаг будет получать одинаковые по смыслу поля независимо от выбранного маршрута.

В результатах положительных ветвей задайте логическое «Да», отрицательной «Нет». Не подменяйте эти значения строками «true» и «false». Принцип настройки путей разобран в статье об условиях, а передача общих выходов в статье о слиянии.

Схема проверяет пустоту телефона, затем email и возвращает готовность с причиной через слияние. Проверка формата и существования канала связи здесь не показана.

Пустое поле и пробелы требуют разных правил

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

Точно так же непустой текст «не знаю» не становится номером телефона. Для этой статьи правило ограничено заполнением переданных входов. Проверку формата номера или email нужно проектировать и проверять отдельно.

Не меняйте смысл признака ready без изменения описания и тестов. Если сегодня он означает «есть непустой канал», следующий робот не должен воспринимать его как «клиент прошёл все проверки».

Пустая строка и строка пробелов могут обрабатываться по-разному. Непустое значение ещё не подтверждает правильность номера.

Проверьте положительные и отрицательные результаты

Запустите проверку схемы, затем моделирование с синтетическими значениями.

Дополнительно проверьте пробелы, неверный тип и отсутствие входа. Для каждого случая заранее определите ожидаемое поведение. Случайный результат нельзя принимать только потому, что схема завершилась.

Отрицательная бизнес-проверка должна возвращаться как осмысленный результат ready=false с причиной. Ошибка исполнения означает другое: правило не удалось вычислить. Эти состояния требуют разных действий.

ready=false при успешном исполнении является отрицательным бизнес-результатом, а не ошибкой робота.

Модель выполнена успешно, но ready=false: «Нет телефона и email». Это отрицательный бизнес-результат, а не техническая ошибка.

При пустом телефоне и заполненном email модель вернула ready=true: «Канал связи указан». Существование адреса и доставка письма не проверялись.

Как использовать результат дальше

Следующему роботу нужны два условия: наш сценарий успешно завершился и его ready имеет значение «Да». Например, успех можно проверять через swb_ok=Да или swb_status=succeeded, а готовность через объявленный выход.

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

После моделирования проверьте подключённую версию на тестовых лидах. Сопоставление реальных полей и получение результата следующим шагом требуют проверки в портале. Пример относится к CRM с лидами; на Базовом тарифе такая сущность недоступна.

Частые вопросы