Это решает задачу передачи данных после выбора. Настройка самого сравнения разобрана в статье об условиях робота. Здесь рассмотрим, как две разные истории получения контакта превращаются в один понятный результат для привязки к лиду.
Почему общей линии на схеме недостаточно
Представим, что поиск нашёл контакт. Его ID доступен в результате блока поиска. В другом запуске контакт не найден, поэтому его создаёт отдельный блок. Теперь нужный ID находится в результате создания.
Следующий шаг в обоих случаях одинаков: привязать выбранный контакт к лиду. Но привязке нельзя постоянно брать ID только из создания. При найденном контакте этот блок пропускается. Брать ID только из первоначального поиска тоже неверно: в ветви создания поиск вернул отсутствие контакта.
Слияние явно отвечает на вопрос: какое значение считать общим contact_id после каждого пути? Вместе с ним удобно передать признак created, чтобы дальше различать новый и существующий контакт.
Какие выходы объявить
В контактном примере добавьте в «Слияние ветвей» два выхода через «Добавить выход»:
| Код | Смысл |
|---|---|
contact_id |
ID контакта, с которым нужно продолжить работу |
created |
Создал ли этот запуск новый контакт |
Коды должны оставаться понятными и постоянными внутри схемы. Используйте один код для одного смысла. Например, created отвечает за факт создания контакта, а успешность всей автоматизации проверяется отдельно.
У контактного ID должен быть согласованный числовой тип. Для признака создания используйте «Да/нет». Не превращайте ID в текст только потому, что его удобно показать в подписи.
Сопоставьте значения для каждого пути
У слияния должны быть входящие связи от двух маршрутов: прямо из выхода «Да» условия и из блока «Создать контакт из лида». После этого заполните значения по таблице.
| Входящая ветвь | Источник contact_id |
Источник created |
|---|---|---|
| Контакт найден, создание пропущено | ID контакта из поиска | Постоянное «Нет (false)» |
| Выполнен блок создания | ID контакта из создания | «Контакт создан» из создания |
Во второй строке не подставляйте постоянное «Да». Блок создания перед записью повторно проверяет связи лида и поиск. Если контакт уже появился, блок может вернуть существующий ID с created=false. Слияние должно сохранить этот фактический результат.
После изменения связей нажмите «Обновить строки по входящим ветвям», если список требует обновления. Затем снова проверьте каждую строку. Удалённая или перенаправленная связь не должна оставить прежнее сопоставление, смысл которого уже изменился.
В ветви создания нельзя подставлять постоянное «Да»: повторная проверка может найти существующий контакт.
Для найденного контакта ID берётся из поиска, created задан как false. Для ветви создания оба результата берутся из блока создания. Это настройка выходов слияния.
Подключите общий следующий шаг
Для блока «Привязать контакт к лиду» задайте два источника. ID лида берите из параметра текущего робота, а ID контакта из выхода contact_id блока слияния.
Теперь привязке не требуется знать, какая ветвь работала. Она получает один и тот же по смыслу вход. Выход created сохраните для блока «Результат» вместе с ID контакта после успешной привязки.
Общая последовательность получается такой: поиск → условие → выбранный путь → слияние → привязка → результат. Слияние не ждёт параллельные ветви и не запускает пропущенный блок. Оно выбирает сопоставления фактически пройденного пути.
Точная схема и настройка контактных блоков доступны в пошаговом руководстве. Она предназначена для порталов с лидами и не переносится на Базовый тариф простой заменой названий сущностей.
Слияние не выполняет обе ветви. Оно берёт ID и признак создания из фактически пройденного пути.
Проверьте данные на трёх вариантах
Для слияния двух тестов иногда мало. Контактная схема требует третьего варианта, в котором контакт найден повторной проверкой уже внутри блока создания.
| Вариант | Что должно выйти из слияния |
|---|---|
| Первичный поиск нашёл контакт | Его ID, created=false |
| Поиск не нашёл, создание выполнилось | Новый ID, created=true |
| Поиск не нашёл, но перед созданием контакт обнаружен | Возвращённый блоком создания ID, created=false |
В моделировании задайте согласованные синтетические ответы поиска, создания и привязки. Во втором и третьем вариантах ID из ответа создания должен дойти до входа привязки и до итогового результата.
Проверьте итоговую строку и выполненные шаги. Если оба результата выглядят правдоподобно, ошибка сопоставления может остаться незаметной: например, новый ID заменится старой тестовой константой.
Моделирование не меняет CRM и не доказывает реальную привязку. На тестовом портале дополнительно откройте лид и убедитесь, что нужный контакт действительно связан.
Первый вариант модели: найден существующий контакт, итог contact_id=501 и created=false. Данные синтетические.
Второй вариант модели: ветвь создания возвращает contact_id=501 и created=true. Это результат имитации, а не запись в CRM.
Третий вариант: первоначальный поиск задан как отрицательный, а ответ блока создания — уже существующий ID 501 и created=false. Этот кадр не подтверждает реальную повторную проверку CRM.
Что проверить при пустом результате
Начните со строки выполненной ветви. Убедитесь, что для неё заполнены все общие выходы и источником выбран доступный блок этого пути. Затем проверьте привязки следующего шага: они должны ссылаться на слияние, а не на прежний источник.
Сравните типы. Пустое значение, нулевой ID и отсутствие поля имеют разный смысл. Для успешной привязки нужен настоящий положительный ID контакта, а не «значение на всякий случай».
Частые вопросы
Слияние выполняет обе ветви?
Нет. В этой схеме выполняется выбранный путь, а слияние берёт его данные. Параллельного выполнения такое соединение не создаёт.
Почему после блока создания вернулся признак «Нет»?
Повторная проверка могла найти уже существующий контакт. Поэтому передавайте выход блока создания, сохраняя его фактический результат.
Можно ли после слияния сразу запускать следующий робот?
Следующему роботу настройте отдельное условие успешного завершения, например swb_ok=Да или swb_status=succeeded. Наличие выходов слияния само по себе не подтверждает успех привязки.





