Изменение поля — самая частая операция в CRM, и у неё две стороны. Первая — как менять поля автоматически: роботом, процессом, запросом по API, сразу у тысячи сделок. Вторая — как реагировать, когда поле поменял кто-то другой: запустить процесс, проверить новое значение, понять, кто и когда правил карточку. Разберём обе — от одного кубика в сделке до массового обновления базы.

Как изменить поле роботом?

Штатный робот «Изменить элемент» правит поля той сущности, на которой работает: выбрали поле, задали значение — при попадании на стадию оно запишется. Когда полей несколько, удобнее один робот вместо пяти: «Обновить сделку по ID» принимает JSON, где ключи — коды полей, и записывает всё разом: {"stageId":"C1:WON","opportunity":50000,"ufCrm_1721244707107":"…"}. Коды берутся из настроек CRM или методов *.fields — подробно в разборе ID полей. Отдельная история — очистка: пустая строка не обнуляет списки, даты и множественные поля, поэтому для «стереть значение» есть робот «Очистить поле», который корректно обнуляет любой тип.

Как изменить поле связанной сущности?

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

Как изменить поле через API или вебхук?

Точечно и из внешних систем поля меняют REST-запросом. Универсальный метод crm.item.update принимает ID элемента, тип сущности и объект fields — передавать нужно только то, что меняется, остальные поля не трогаются. Коды полей в нём пишутся в camelCase (title, opportunity, assignedById), пользовательские — ufCrm с числом. Старое поколение методов (crm.deal.update) использует те же поля в верхнем регистре — TITLE, UF_CRM_…; путаница регистров — первая причина «запрос прошёл, а поле не изменилось». Для интеграций достаточно входящего вебхука с правами на CRM — как его создать, разобрано в гайде по вебхукам.

Как запустить автоматизацию при изменении поля?

Обратная задача: поле поменялось — нужно отреагировать. В роботах за это отвечает триггер «изменилось поле»: он переносит элемент на выбранную стадию, а дальше работают роботы этой стадии. Триггер не различает, на какое значение поменялось поле, поэтому первым роботом стадии ставят «Сложное условие» — оно проверяет комбинацию полей и возвращает Y/N. Классические бизнес-процессы умеют запускаться «при изменении» документа — вариант, когда логика сложнее одной стадии. Как устроены триггеры и чем они отличаются от роботов — в отдельном разборе.

Кто и когда изменил поле?

Карточка хранит системные поля «Дата изменения» и «Кто изменил» — они отвечают про последнюю правку карточки в целом, но не скажут, какое именно поле трогали и что было до этого. Часть событий видна в таймлайне — смена стадии, смена ответственного, — а отдельного журнала «все правки этого поля» интерфейс не показывает. Если конкретное поле нужно контролировать, контроль строится процессом: запуск «при изменении», проверка значения условием и комментарий в таймлайн или уведомление руководителю — самодельный журнал, который фиксирует ровно то, что важно. А чтобы критичные поля не оставались пустыми, перед сменой стадии или генерацией документа ставьте «Проверить заполненность поля».

Как изменить поле сразу у всей базы?

Групповое редактирование в списке CRM закрывает простые случаи: отметили элементы — задали значение. Когда нужна логика — заполнить поле по условию, пересчитать из других полей, почистить мусор, — соберите шаблон из роботов изменения и запустите его по всей выборке через массовый запуск бизнес-процессов: фильтр, шаблон, и к утру база обновлена. Тот же приём размечает базу задним числом после добавления нового поля — старые записи не остаются пустыми.

Итог

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