Бизнес-процесс в Битрикс24 всегда знает запись, на которой запущен, — и почти ничего о записях вокруг неё. При этом половина реальных сценариев начинается с поиска: есть ли уже такой клиент, открыта ли по нему сделка, создана ли задача на повторный контакт? Штатного действия поиска в дизайнере нет, поэтому процессы либо пропускают проверку и плодят дубли, либо ходят через внешние скрипты. В этой статье — как роботы поиска закрывают пробел: ищем по любому полю, получаем ID и признак «найдено», дальше ветвимся, связываем и обновляем.

Зачем искать записи из бизнес-процесса?

Потому что запись-триггер редко исчерпывает историю. Новое обращение приходит лидом, но человек может уже быть контактом с историей покупок. Заявка в поддержку ссылается на компанию с открытой сделкой, к которой процессу стоит присоединиться, а не создавать параллельную. Смена стадии должна обновить задачу на повторный контакт — если та существует. В каждом случае процессу нужен ответ на вопрос «есть ли запись, где поле X равно значению Y», причём значение берётся из полей текущей записи.

Как работает поиск по условию?

Один поиск — один вызов робота. «Найти контакт по телефону/email» сопоставляет людей по самым стабильным идентификаторам; «Найти сделку по условию» и «Найти лид по условию» ищут по настроенной вами паре «поле — значение». Каждый возвращает в переменные процесса две вещи: ID найденной записи и признак Y/N — найдена ли она. Именно этот признак делает приём безопасным: процесс явно ветвится по нему (механика условий — здесь), а для составных проверок вроде «найдено И стадия открыта» есть «Сложное условие (AND / OR / NOT)». Одно практическое требование: поиск по телефону работает, только когда номера хранятся единообразно, — сначала выполните проход форматирования телефонов, иначе одинаковые номера будут выглядеть для сравнения разными.

Что делать с найденным ID?

ID — опора для всех последующих шагов. Роботы обновления — «Обновить сделку по ID», «Обновить контакт по ID» — записывают поля в найденную запись, а не в текущую. «Получить значение поля связанной сущности» и «Записать значение в поле связанной сущности» переносят данные между ними. А когда ничего не нашлось, ветка «иначе» создаёт запись штатными средствами — и на обоих путях процесс сходится к одному итогу: ровно одна запись с актуальными данными.

Как поиск предотвращает дубли?

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

Работает ли это для задач и смарт-процессов?

Да, тот же приём выходит за пределы классической CRM. «Найти задачу по условию» отвечает, нет ли уже открытой задачи на повторный контакт, прежде чем процесс создаст следующую. «Найти элемент смарт-процесса» ищет записи пользовательских сущностей — подписки, отгрузки, активы, — которые штатный дизайнер из процессов других сущностей не видит; что такое смарт-процессы и когда они нужны — в руководстве по смарт-процессам.

Что дальше

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