Проектирование пользовательских полей CRM Битрикс24
Проектирование пользовательских полей CRM Битрикс24
Пользовательские поля — самый частый способ «сломать» CRM незаметно. Добавить поле — дело пяти минут. Но через год в системе накапливается 80 полей, половина никогда не заполняется, треть — дублируют друг друга, а одно критичное поле создали с типом «строка» вместо «список» и теперь в аналитике 40 вариантов написания слова «Москва».
Технические основы
Пользовательские поля в Битрикс24 CRM создаются через модуль main (класс CUserTypeManager) и хранятся в двух местах:
-
Описание поля — таблица
b_user_field:ENTITY_ID(например,CRM_LEAD,CRM_DEAL,CRM_CONTACT,CRM_COMPANY,CRM_SMART_*),FIELD_NAME(с префиксомUF_CRM_),USER_TYPE_ID(тип: string, integer, double, boolean, datetime, enumeration, iblock_section, crm_status, employee и т.д.). -
Значения полей — таблицы
b_uts_crm_lead,b_uts_crm_deal,b_uts_crm_contact,b_uts_crm_company— по одной строке на каждую запись сущности.
Поля типа enumeration (список) хранят значения отдельно в b_user_field_enum. Это важно при миграции данных: нельзя просто скопировать числовое значение из поля-списка между средами — ID значений будут разными.
Типы полей и когда какой выбирать
| Тип | USER_TYPE_ID | Когда использовать |
|---|---|---|
| Строка | string |
Произвольный текст: имя, комментарий |
| Целое число | integer |
Количество, ID, номер |
| Число с дробью | double |
Сумма, процент, вес |
| Список | enumeration |
Фиксированный набор значений — статусы, типы, категории |
| Дата | date |
Дата без времени |
| Дата+время | datetime |
Дата со временем |
| Флаг (Да/Нет) | boolean |
Бинарный признак |
| Файл | file |
Документы, изображения |
| Привязка к сотруднику | employee |
Ответственный, куратор |
| Привязка к элементу CRM | crm |
Связь со сделкой, контактом, компанией |
| Деньги | money |
Суммы с валютой |
Выбор «строка» вместо «список» — самая распространённая ошибка. Если значение берётся из конечного набора вариантов — это список. Всегда.
Процесс проектирования полей
Шаг 1. Инвентаризация существующих полей. На живых проектах нередко обнаруживается 50–100 пользовательских полей на одну сущность. Часть создана разными людьми в разное время, часть дублирует стандартные поля, часть никогда не заполнялась. Проводим аудит: какие поля используются, кем, для чего.
Шаг 2. Выявление потребностей. Для каждого отдела-пользователя CRM фиксируем: что они хотят видеть в карточке и что хотят получать в отчётах. Отчёты — ключевой ориентир: если данные нельзя агрегировать, поле с неправильным типом.
Шаг 3. Нормализация значений списков. Для полей типа «список» проектируем финальный набор значений. Правило: значений должно быть достаточно для классификации, но не настолько много, чтобы менеджер не мог выбрать за 3 секунды. 5–12 значений — рабочий диапазон. Если нужно больше — рассматриваем двухуровневый список или справочник через смарт-процесс.
Шаг 4. Именование полей. Системное имя (FIELD_NAME) должно быть осмысленным: UF_CRM_DEAL_REASON_LOSS вместо UF_CRM_1234567. Это критично при интеграциях через REST API и при диагностике.
Шаг 5. Порядок отображения и обязательность. Для каждого поля фиксируем: обязательное или нет, на каких стадиях обязательное, в каком блоке карточки отображается.
Антипаттерны
Поле «Комментарий» вместо структурированных данных. «Причина отказа» как текстовое поле — это журнал, а не аналитика. Через 6 месяцев там будет 200 уникальных фраз.
Поле «Статус» дублирует стандартный статус CRM. Часто кастомное поле «Внутренний статус» — это просто попытка обойти стадии воронки. Если стадии не устраивают, правильнее перепроектировать воронку.
Поля для данных, которые можно вычислить. Если поле «Сумма с НДС» всегда равно «Сумма» × 1.2 — это не нужно хранить, это нужно вычислять в отчёте.
Избыточная детализация. Поле «Причина выбора нашей компании» с 35 вариантами — менеджеры будут выбирать «Прочее». Лучше 6 категорий и открытый комментарий рядом.
Кейс: аудит и пересборка полей для производственной компании
Клиент — завод металлоконструкций. 47 пользовательских полей в сделке, созданных за 3 года. Задача: привести в порядок перед интеграцией с ERP.
Аудит показал:
- 11 полей типа «строка» с содержимым, которое является перечислением (тип металла, класс прочности, регион поставки)
- 7 полей никогда не заполнялись (все значения NULL)
- 4 поля дублируют друг друга («Объём заказа» и «Количество тонн» — одно и то же разными словами)
- 2 поля имеют неправильный тип: дата прописана как строка в формате «дд.мм.гг»
Результат пересборки: 47 → 28 полей. Строковые поля с перечислениями переведены в enumeration, данные мигрированы через API. Дублирующие поля объединены. Неиспользуемые — удалены после экспорта данных в архив.
После нормализации интеграция с ERP заняла вдвое меньше времени — чистый маппинг полей вместо разбора произвольного текста.
Сроки
Аудит и проектирование пользовательских полей для одной сущности — 2–4 дня. Для всего CRM (лид, сделка, контакт, компания) — 8–14 дней с учётом миграции данных в новые типы и согласования с заказчиком.