Користувацькі поля — найчастіший спосіб «зламати» 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