Пользовательские поля — самый частый способ «сломать» CRM незаметно. Добавить поле — дело пяти минут. Но через год в системе накапливается 80 полей, половина никогда не заполняется, треть — дублируют друг друга, а одно критичное поле создали с типом «строка» вместо «список» — и теперь в аналитике 40 вариантов написания слова «Москва».
Проектирование с нуля или рефакторинг хаоса — разница в производительности CRM в 2 раза. Правильно спроектированные поля сокращают время на поиск информации на 40% и исключают ошибки в отчётах. Мы проектируем поля уже 5 лет, наша команда провела аудит более 50 CRM-систем. Опыт показал: грамотное проектирование сокращает время интеграции с 1С на 30% и исключает ошибки отчётности. Каждое лишнее поле — лишний JOIN в запросах к b_uts_crm_deal. Оптимизация структуры ускоряет работу карточки сделки на 25%. Закажите аудит — и получите порядок в CRM.
Почему проектирование полей критично для CRM?
В Битрикс24 пользовательские поля создаются через модуль main (класс CUserTypeManager) и хранятся в двух таблицах:
-
Описание поля —
b_user_field:ENTITY_ID(например,CRM_LEAD,CRM_DEAL,CRM_CONTACT,CRM_COMPANY,CRM_SMART_*),FIELD_NAME(с префиксомUF_CRM_),USER_TYPE_ID. -
Значения полей —
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 |
Суммы с валютой |
Выбор «строка» вместо «список» — самая распространённая ошибка. Если значение берётся из конечного набора — это список. Всегда.
| Антипаттерн | Решение |
|---|---|
| Текстовое поле «Причина отказа» | Заменить списком + комментарием |
| Кастомный статус, дублирующий стадии воронки | Перепроектировать воронку |
| Поле для вычисляемых данных (сумма с НДС) | Удалить, вычислять в отчётах |
| Слишком много значений списка (>15) | Разбить на категории или использовать справочник |
Типичные ошибки при создании пользовательских полей
- Использование типа «строка» для данных с ограниченным набором значений — вместо списка.
- Создание полей с одинаковым смыслом разными сотрудниками (дубли).
- Именование полей без префикса
UF_CRM_— нарушение конвенции Битрикс. - Слишком много значений в списке (>15) — список становится неудобным.
Как мы проектируем поля: процесс
- Инвентаризация. На живых проектах часто обнаруживается 50–100 полей на сущность. Часть создана разными людьми, часть дублирует стандартные, часть не используется.
- Выявление потребностей. Для каждого отдела фиксируем, что нужно в карточке и что важно для отчётов.
- Нормализация значений списков. 5–12 значений — рабочий диапазон. Если больше — двухуровневый список или смарт-процесс.
- Именование.
UF_CRM_DEAL_REASON_LOSSвместоUF_CRM_1234567— критично для REST API и диагностики. - Порядок и обязательность. Обязательные поля, стадии, блоки карточки.
Проектирование полей в 2 раза быстрее интеграции по сравнению с хаотичной структурой — это подтверждает наша практика.
Что входит в нашу работу
- Аудит всех пользовательских полей на сущности
- Проектирование новой структуры с учётом бизнес-процессов
- Миграция данных из старых полей в новые
- Документация по API и интеграциям
- Обучение сотрудников работе с новыми полями
Кейс: аудит и пересборка полей для производственной компании
Наш клиент — завод металлоконструкций. 47 пользовательских полей в сделке, созданных за 3 года. Задача: привести в порядок перед интеграцией с ERP.
Аудит показал:
- 11 полей типа «строка» с содержимым, которое является перечислением (тип металла, класс прочности, регион поставки)
- 7 полей никогда не заполнялись (все NULL)
- 4 поля дублируют друг друга («Объём заказа» и «Количество тонн»)
- 2 поля с датой как строка
Результат пересборки: 47 → 28 полей. Строковые поля переведены в enumeration, данные мигрированы через API. Дублирующие объединены. Неиспользуемые удалены после экспорта в архив.
После нормализации интеграция с ERP заняла вдвое меньше времени — чистый маппинг полей вместо разбора произвольного текста.
Сроки
Аудит и проектирование для одной сущности — 2–4 дня. Для всего CRM (лид, сделка, контакт, компания) — 8–14 дней с учётом миграции данных и согласований.
Закажите проектирование полей — и забудьте о проблемах с отчётностью. Получите консультацию через форму на сайте.
Документация 1С-Битрикс: Пользовательские поля | CRM-система на Wikipedia