Странная мелочь — число вроде 27 — а из‑за него рушатся согласования, не создаются задачи и летят вебхуки. Речь про ID сотрудника в Битрикс24. Пока он неявно “приклеен” к полю “Ответственный” — всё нормально. Как только вы тянете его в бизнес‑процесс, робота или внешний запрос, начинаются сюрпризы.
Разберём быстро и по делу: где теряется ID, как понять, что всё уже сломано, и что проверить в первую очередь. Это не теория — это аудит по чек‑листу, который мы используем на внедрениях.
Где теряется ID пользователя в бизнес-процессе
Чаще всего ID теряется на границе типов данных. В Битрикс24 поле “Пользователь” возвращает не просто число, а значение формата user_123. Для одних действий это ок (согласования, постановка задач), а для других — нет (вебхуки, REST, интеграции). На практике чаще всего ломается связка: пользовательское поле → вебхук, где ждут чистый numeric ID.
Второй источник потерь — копирование шаблонов. Перенесли робот между воронками, а в новом шаблоне уже нет поля ASSIGNED_BY_ID или оно называется по‑другому. Внешне всё красиво, но выражение ссылается на пустоту. Обычно всплывает одна и та же ошибка: “не удалось определить пользователя”.
Третий кейс — согласования с ролями. Выбрали “Руководитель подразделения” от условного сотрудника, а сам сотрудник подставляется из мультисписка. В логе получается массив пользователей, а шаг ждёт одного конкретного ID. Итог — пауза без движения.
Какие признаки показывают, что настройка сломана
Если система настроена правильно, роботы “назначают”, согласования “берут в работу”, а интеграции получают чистый ID. Когда нет — видно сразу.
- В ленте бизнес‑процесса: “Пользователь не найден” или подстановка user_XXX в поле, где ждут число.
- Роботы не создают задачу или создают без ответственного — висит “Без постановщика/назначено на Портал”.
- Согласование замирает на первом шаге: участник не определён, статус “Ожидание”.
- Вебхук ругается 400/401/422, а в логе видно, что передали “user_58” вместо “58”.
- В полях CRM смешались форматы: в одном месте хранится число, в другом — user_число, и фильтры по ним не работают.
Проверяем способы получения ID без хаоса
Начинаем с источников, где ID уже есть числом. В CRM это системные поля с “_ID” на конце: ASSIGNED_BY_ID, CREATED_BY_ID, MODIFY_BY_ID. Если задача — получить ID пользователя в Битрикс24 для интеграции или REST, используйте именно эти поля. Хороший признак — когда ключевые роботы цепляются за стандартные поля, а не за набор “самописных” переменных.
Дальше — инициатор процесса. В шаблонах БП есть токен Initiator. Сам по себе он даёт user_XXX, но сдвиг простой: добавляете “:ID” и получаете чистое число. Точно так же обрабатываются переменные/параметры типа “Пользователь”: значение, выражение:ID — и можно безопасно отправлять наружу. Это тот самый ответ на вопрос “как получить ID пользователя в Битрикс24, если в руках только пользовательское поле”.
Ниже короткая шпаргалка, чтобы не гадать, откуда брать и что подставлять.
| Где берём | Что подставлять | Комментарий |
|---|---|---|
| Ответственный по сделке/лиду/контакту | {=Document:ASSIGNED_BY_ID} | Чистый ID, безопасен для REST и интеграций. |
| Кто создал запись | {=Document:CREATED_BY_ID} | Работает в CRM; в других модулях может быть CREATED_BY (тогда добавляйте :ID). |
| Инициатор бизнес‑процесса | {=Template:Initiator:ID} | Без “:ID” вернётся user_XXX — не подойдёт для внешних вызовов. |
| Параметр/переменная типа “Пользователь” | {=Variable:UserVar:ID} | Суффикс :ID превращает user_XXX в число. |
| Результат шага “Выбрать сотрудника” | {=Activity:SelectUser:ID} | Для множественных значений используйте цикл по списку. |
| Руководитель сотрудника | Выбор через структуру, затем :ID | Определяйте сначала пользователя, потом вытягивайте его руководителя. |
Что делать, если ID нужен в согласованиях и роботах
Если вы настраиваете согласование — подавайте на вход именно “пользователя”, не число. Списки согласующих, роли, департаменты — это всё сущности типа Пользователь/Группа. Для входящих выражений держите формат user_XXX, а для исходящих (в вебхук, REST, внешний сервис) — используйте тот же токен с постфиксом :ID. На практике это решает до 80% конфликтов между шагами БП и интеграциями.
Микро‑сценарий. Согласование договора: сначала руководитель ответственного, потом юрист. В роботе: 1) Берём {=Document:ASSIGNED_BY_ID} → находим руководителя через “Выбрать из структуры” (от сотрудника). 2) Передаём результат шага в список согласующих (оставляем формат user_XXX). 3) Параллельно отправляем вебхуку ID согласующего — через {=Activity:SelectManager:ID}. Никаких ручных парсеров, всё стандартно.
Если требуется запускать робота “от имени” — используйте системные опции исполнения от ответственного/инициатора или задавайте переменную типа Пользователь и подставляйте её в поле “Кто выполняет”. Там формат user_XXX уместен. А вот когда этот же робот инициирует внешний запрос, не забывайте конвертировать в число через :ID.
Типовые ошибки, из-за которых процесс не работает
Ошибки повторяются. Их видно уже на втором‑третьем клике по логу.
- Передают user_XXX в HTTP‑запрос, где ждут integer — интеграция падает с 400/422.
- Ссылаются на CREATED_BY (без _ID) в CRM — в одном шаблоне это работает, в другом нет.
- Множественное поле “Пользователи” пытаются сунуть туда, где нужен один человек — шаг зависает.
- Копируют робота между воронками — поля с другими кодами, ссылки на старые токены пустые.
- Жёстко вшивают конкретные ID вместо ролей/структуры — всё ломается при перестановках.
- Смешивают собственные переменные и системные поля, не фиксируя единый формат хранения.
- Нет логирования: невозможно понять, что ушло во внешний сервис — число или user_XXX.
Что исправить в первую очередь, чтобы автоматизация пошла
Первое — стандартизируйте источник истины. Для CRM‑сущностей опирайтесь на поля с постфиксом _ID. Для согласующих и исполнителей внутри портала — используйте тип “Пользователь” и не преобразуйте раньше времени. Это снижает количество лишних “форматирований” и точек отказа.
Второе — зафиксируйте правило конвертации. Внутри портала работаем с user_XXX, при выходе наружу добавляем :ID. Элементарно, но именно это правило чаще всего не проговаривают, и дальше всё расходится: кто‑то режет префикс строкой, кто‑то хранит число, кто‑то — токен.
Третье — заведите короткий тестовый контур. Один лид/сделка, один шаблон, включённые логи на ключевых шагах: что пришло, что ушло. Хороший признак — когда за 2–3 запуска видно стабильные значения и не плавают типы данных. Если что‑то не так — чините на ближайшем шаге, не переписывая весь процесс.
Четвёртое — пройдитесь по “узким местам”: мультипользовательские поля переводите в цикл “для каждого”; при переносе роботов перепривязывайте поля к локальным кодам; роли задавайте через структуру (руководитель, отдел), а не через жёсткие ID. На практике чаще всего это снимает большинство подвисаний согласований и ошибок назначения.
Если нужно быстро навести порядок, начните с мини‑аудита шаблонов: проверьте источники ID, выровняйте формат и включите логи на критичных шагах. Готовы помочь: проведём экспресс‑проверку и настроим конвертацию user → ID там, где это реально нужно. Напишите нам — команда AMSALES настроит автоматизации и интеграции в Битрикс24 под ваши процессы: настройка автоматизаций и интеграций Битрикс24.
