В смарт-процессе на определённой стадии нужно автоматически подставлять «актуальный бренд» из лида. Источник — поле лида типа «Список» (множественное), а целевое значение должно подтягиваться из универсального списка «Бренды», чтобы в смарт-процессе сохранялись корректные элементы и их идентификаторы.
В чём была проблема
Когда в поле «Бренд» в лиде выбран один вариант, поиск отрабатывал ожидаемо: возвращались найденные элементы, минимальный ID и количество. Но как только в лиде выбирали два и более бренда, результат становился пустым: в уведомлениях и дальнейших шагах не появлялись ни массив, ни ID, ни число найденных элементов.
Почему стандартная логика “вставить поле и искать” не работает
Поле типа «Список» в множественном режиме фактически возвращает набор значений. Если подставить его в параметр поиска как одно значение, на практике это превращается в строку вроде «бренд1, бренд2, бренд3» (или в сложное представление результата действия). Для поиска по полю списка это некорректный вход: поиск ожидает одно значение, а не «сразу всё в одной строке».
Решение: переменная + итератор + поиск по каждому бренду
Чтобы корректно обработать множественные бренды, применили “двухшаговую” схему:
- В шаблоне БП добавили переменную:
- тип: Строка
- множественная: Да
- идентификатор: на английском (например, NameBrand)
- После шага «Получить информацию о привязанном элементе» записали в эту переменную результат (массив брендов из лида).
- Запустили «Итератор» и в качестве источника указали именно переменную, а не напрямую результат предыдущего действия (так надёжнее, потому что итератор может нестабильно работать с “результатами поиска”, а с переменной — предсказуемо).
- Внутри итератора разместили действие поиска и передали в него текущее значение итератора (то есть один бренд за шаг).
- Найденные элементы универсального списка складывали в целевое поле смарт-процесса, также множественное (обычно строка или аналогичное поле под вашу модель данных).
Пример логики в виде “псевдокода” обычным текстом
Переменная NameBrand = [бренд1, бренд2, бренд3]
Итератор(источник = NameBrand):
— текущий_бренд = ЗначениеИтератора
— результат = ПоискВСписках(список = “Бренды”, поле_поиска = текущий_бренд)
— ДобавитьВСмартПроцесс(поле_бренды = результат.ID_найденных_элементов)
Результат
После перехода на схему “переменная → итератор → поиск по одному значению” поиск начал стабильно возвращать результаты и для одного бренда, и для нескольких. Смарт-процесс стал заполняться корректно, без ручной обработки и без потери значений.
Вывод
Если вы строите связку “множественное поле в CRM → поиск в универсальном списке → запись в смарт-процесс”, то ключ к стабильной работе — не пытаться искать “всем списком сразу”, а разложить данные на отдельные элементы. В таких задачах Поиск элементов Списка по любым полям удобно использовать как поисковый механизм, а итератор и множественная переменная превращают его в предсказуемый конвейер обработки значений. На практике эта же схема масштабируется и на любые другие множественные поля, где нужно поштучно сопоставлять элементы и переносить результаты. Поиск элементов Списка по любым полям в этом сценарии выглядит не как “разовое действие”, а как строительный блок для нормальной логики “как сделать перенос множественных значений без кастомной разработки”.
