Пользовательские поля в Битрикс24: настройка карточек сделки и контакта

Пользовательские поля битрикс24 - первый инструмент, к которому обращаешься, когда типовая карточка сделки или контакта не покрывает бизнес-процесс. У меня на практике таких доработок было десятки: от простого текстового поля «Источник заявки» до связки из пяти полей с автозаполнением через REST API и внешние вебхуки. В этой статье разберу, как создавать поля, какой тип выбирать под конкретную задачу и на что натыкаешься на практике при настройке карточек CRM.

Зачем добавлять пользовательские поля в сделки и контакты

Стандартный набор полей в Битрикс24 закрывает базовые сценарии продаж: имя, телефон, сумма сделки, статус. Как только процесс становится специфичным, полей не хватает. Из моей практики типичные причины завести дополнительное поле:

• Нужно хранить номер накладной СДЭК или трек-номер другой службы доставки прямо в карточке сделки, чтобы менеджер не лазил во внешний сервис.
• Компания продаёт несколько продуктовых линеек, и нужен отдельный список для выбора направления, от которого зависит воронка.
• Есть интеграция с внешней системой, например платёжным шлюзом или складом, и в карточку нужно писать статус синхронизации или ID записи из другой базы.
• Юридические поля: ИНН, форма договора, дата окончания действия коммерческого предложения.
• Поля для аналитики, которые потом выгружаются в BI-дашборд или обрабатываются скриптом в n8n для автоматических отчётов.

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

Как создать пользовательское поле в карточке сделки

Через интерфейс это делается в разделе CRM. Заходишь в настройки карточки сделки, обычно кнопка со шестерёнкой в верхнем углу карточки или раздел «Настройки» - «Поля», выбираешь «Добавить поле» и задаёшь:

• Символьный код поля, например UF_CRM_DELIVERY_TRACK - по нему потом обращаешься к полю через REST API.
• Тип поля: строка, список, дата, привязка к элементу CRM и так далее.
• Название для отображения в карточке и подсказку для менеджера.
• Обязательность заполнения и значение по умолчанию.
• Права доступа на просмотр и редактирование по ролям сотрудников.

Если полей много и создавать их приходится регулярно, например при разворачивании нового филиала или продуктовой линии, быстрее делать это через REST API методом crm.deal.userfield.add. Пример запроса на добавление строкового поля:

curl -X POST 
  "https://your-domain.bitrix24.ru/rest/1/webhook_code/crm.deal.userfield.add" 
  -H "Content-Type: application/json" 
  -d '{
    "fields": {
      "FIELD_NAME": "DELIVERY_TRACK",
      "USER_TYPE_ID": "string",
      "XML_ID": "DELIVERY_TRACK",
      "EDIT_FORM_LABEL": {"ru": "Трек-номер доставки"},
      "LIST_COLUMN_LABEL": {"ru": "Трек"},
      "MANDATORY": "N"
    }
  }'

После добавления поле автоматически получает префикс UF_CRM_ и появляется в карточке сделки без перезагрузки страницы. Такой подход удобен, когда настройка идёт из скрипта миграции или разворачивается вместе с типовым шаблоном портала для нового клиента.

Какой тип поля выбрать: сравнение вариантов

Ошибка, которую вижу чаще всего: под любую задачу берут строковое поле, хотя есть более узкие типы, которые сразу дают валидацию и удобный интерфейс ввода. Собрал таблицу с типами, которые использую регулярно:

Отдельно про тип «Список»: если значений больше 15-20, лучше делать поле «Привязка к элементу CRM» со справочником в виде смарт-процесса, а не раздувать enumeration. С обычным списком на 40 с лишним значений интерфейс выбора в мобильном приложении становится неудобным, менеджеры жалуются в первую же неделю после внедрения.

Настройка пользовательских полей в карточке контакта и компании

Логика создания полей в контакте и компании такая же, как в сделке, но методы REST API другие: crm.contact.userfield.add и crm.company.userfield.add. На практике в карточку контакта чаще всего добавляю:

• Канал первого касания: сайт, мессенджер, звонок, партнёрская рекомендация - список, на основе которого потом строится отчёт по источникам.
• ИНН и реквизиты для B2B-клиентов, если компания не заведена отдельной карточкой.
• Согласие на обработку персональных данных с датой и способом получения согласия.
• ID клиента во внешней системе, если параллельно ведётся учёт в другой базе или интернет-магазине.

Важный нюанс: поля контакта видны во всех сделках этого контакта, а поля сделки живут только внутри одной сделки. Если данные должны «тянуться» за клиентом между разными сделками, например предпочитаемый способ доставки, поле нужно заводить в контакте, а не дублировать в каждой сделке.

Для компаний с большим объёмом входящих обращений через сайт или Telegram-бота дополнительные поля часто заполняются автоматически через вебхук на входящее событие. Если у вас настроена интеграция чат-бота с CRM, маппинг полей стоит продумать заранее, а не переносить его руками после того как накопится пара тысяч карточек без данных. Такие интеграции между сайтом, ботом и CRM обычно закрывают на аутсорсе, потому что маппинг полей и обработка ошибок API занимают больше времени, чем кажется на старте.

Группы полей и порядок отображения в карточке

Когда полей в карточке становится больше 10-15, их стоит разносить по группам, иначе менеджер тратит время на прокрутку в поиске нужного поля. В настройках карточки, не путать с настройками самого поля, можно:

• Создавать разделы карточки и перетаскивать поля между ними.
• Скрывать поля, которые заполняются автоматически и не нужны менеджеру визуально.
• Настраивать разный набор видимых полей для разных воронок продаж - это доступно в редакциях с несколькими направлениями CRM.
• Выносить часть полей в блок «Дополнительно», который по умолчанию свёрнут.

На проектах с несколькими воронками, например розница и опт в одной компании, обычно завожу отдельный набор обязательных полей под каждую воронку через настройку стадий, а не через общий шаблон карточки. Иначе менеджер розницы видит поля для опта и наоборот, и это первое, на что жалуются в течение первой недели после внедрения.

Типичные ошибки при работе с пользовательскими полями Битрикс24

За несколько лет настройки CRM под разные компании набрался список повторяющихся проблем:

• Символьный код поля меняют после того, как на него уже завязана автоматизация или роботы бизнес-процессов - связи ломаются молча, без явной ошибки в интерфейсе.
• Поле типа «Список» создают без значения по умолчанию, и в старых карточках оно остаётся пустым, что путает отчёты.
• Обязательные поля включают на живом портале без предупреждения менеджеров - сделки перестают сохраняться, пока пользователь не поймёт, что именно нужно заполнить.
• Поля создают вручную на каждом из нескольких порталов, тестовом и продакшн, из-за чего коды расходятся и импорт данных между окружениями ломается.
• Не ограничивают права на редактирование полей с чувствительными данными, вроде ИНН и реквизитов, и их видят все сотрудники, а не только те, кто отвечает за документооборот.

Отдельно про синхронизацию с внешними системами: если данные в пользовательские поля пишутся через n8n или другой сценарий автоматизации, логируйте ответы API. Битрикс24 REST API молча возвращает ошибку валидации, если тип значения не совпадает с типом поля, например при попытке отправить строку в поле типа «Дата», и без логов такие сбои находишь только через недели, когда менеджер заметит, что поле не заполнилось у части клиентов.

Частые вопросы

Сколько пользовательских полей можно добавить в карточку сделки?

Жёсткого лимита в интерфейсе нет, но на практике больше 25-30 полей в одной карточке усложняют работу менеджеров и замедляют загрузку карточки в браузере и мобильном приложении. Если данных нужно больше, лучше выносить их в связанный смарт-процесс или в карточку компании.

Можно ли изменить тип уже созданного пользовательского поля?

Через стандартный интерфейс нет, тип поля после создания не меняется. Приходится создавать новое поле с нужным типом и переносить данные скриптом через REST API, а старое поле скрывать или удалять после переноса.

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

Вручную это делают через одинаковые символьные коды при создании полей на обоих порталах. Для регулярного переноса удобнее написать скрипт на Python или сценарий в n8n, который читает список полей через crm.deal.userfield.list на одном портале и создаёт их на другом теми же методами add.

Видны ли пользовательские поля в отчётах и фильтрах CRM?

Да, поля типа «Список», «Дата», «Деньги» и «Флажок» сразу доступны в фильтрах и в конструкторе отчётов. Поля типа «Файл» и «Привязка к элементу CRM» в стандартных отчётах фильтруются с ограничениями, для сложной аналитики по ним данные обычно выгружают во внешний BI-инструмент через API.