Проектування користувацьких полів 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 днів з урахуванням міграції даних у нові типи та погодження із замовником.