Розробка користувацьких розділів у Bitrix24
Стандартні розділи Bitrix24 — CRM, Завдання, Диск — охоплюють типові сценарії. Але коли бізнесу потрібен розділ «Запити на закупівлю» зі своєю логікою узгодження, маршрутизацією за ролями та користувацьким інтерфейсом — вбудованих інструментів недостатньо. Універсальні списки та смарт-процеси вирішують частину задач, але мають обмеження інтерфейсу. Тут розпочинається розробка користувацького розділу.
Архітектура користувацького розділу
Користувацький розділ у Bitrix24 — це додаток, вбудований у ліве меню портала через механізм placement. Технічно це SPA, завантажена в iframe всередині інтерфейсу Б24. Реєстрація відбувається через REST API метод placement.bind з типом LEFT_MENU.
Точка входу — файл, що надається вашим сервером (або функцією без сервера). Bitrix24 завантажує його в iframe, передаючи параметри авторизації: AUTH_ID, REFRESH_ID, member_id. Через ці параметри додаток отримує доступ до REST API портала.
BX24.init(function() {
BX24.callMethod('user.current', {}, function(result) {
// Поточний користувач для перевірки прав
});
});
Ключове рішення на старті: де зберігати дані розділу — у сутностях Bitrix24 (смарт-процеси, списки) чи у зовнішній БД. Від цього залежить все інше.
Варіант 1: дані у смарт-процесах
Смарт-процеси (\Bitrix\Crm\Service\Factory) — конструктор CRM-сутностей. Ви створюєте тип через CRM → Параметри → Автоматизація → Смарт-процеси, додаєте користувацькі поля, налаштовуєте воронку. Дані зберігаються в таблицях b_crm_dynamic_items_*.
Користувацький розділ у цьому випадку — альтернативний інтерфейс для роботи з даними смарт-процесу. Замість стандартної карточки та канбану ви малюєте свій інтерфейс, а дані читаєте та записуєте через REST:
-
crm.item.list— отримання списку елементів -
crm.item.add/crm.item.update— створення та оновлення -
crm.item.fields— метаданні поля
Переваги: безкоштовно отримуєте воронки, роботів, бізнес-процеси, права доступу, історію змін. Обмеження: REST API повертає максимум 50 елементів за запит; для великих списків потрібна пагінація. Для 10 000+ записів інтерфейс має реалізувати серверну фільтрацію.
Варіант 2: зовнішня БД
Коли дані складніші, ніж плоский список з полями — зв'язки "багато-до-багатьох", ієрархії, специфічні індекси — простіше зберігати у зовнішній PostgreSQL або MySQL. Користувацький розділ звертається до вашого бекенда через API, а з Bitrix24 взаємодіє лише для авторизації та отримання контексту користувача.
Схема: iframe завантажує SPA → SPA перевіряє AUTH_ID через oauth.bitrix.info/rest/ → отримує user_id → запитує дані з вашого бекенда за user_id.
Переваги: без обмежень REST API, повний контроль над структурою даних. Обмеження: втрачаєте вбудованих роботів та бізнес-процесів; права доступу потрібно реалізувати самостійно.
Інтеграція з інтерфейсом Б24
Для ощущення нативності користувацький розділ має використовувати систему дизайну Bitrix24. Офіційний UI-кіт: @bitrix24/b24-ui. Він містить компоненти, візуально ідентичні стандартним елементам портала — кнопки, таблиці, фільтри, слайдери.
Ключові точки інтеграції:
-
Слайдер — відкриття карточки елемента в боковій панелі через
BX24.openApplication({bx24_width: 800}) -
Лічильники в меню — оновлення бейджа через
BX24.appOption.set('bx24_leftMenuCounter', count) -
Сповіщення — надсилання через
im.notify.system.addдля сповіщення користувачів про події в розділі
Права доступу
Якщо дані у смарт-процесах — права успадковуються з CRM (ролі в параметрах прав CRM-сутності). Для зовнішної БД реалізуйте перевірку через REST-метод user.current + відображення ролей Б24 на ролі вашого додатка.
Для перевірки належності до відділу: department.get повертає структуру, user.get з фільтром за UF_DEPARTMENT — користувачів підрозділу.
Оцінка трудомісткості
| Компонент | Оцінка |
|---|---|
| Скелет додатка + реєстрація в Б24 | 1–2 дні |
| CRUD-інтерфейс списку (таблиця, фільтри) | 3–5 днів |
| Карточка елемента зі слайдером | 2–3 дні |
| Права доступу (зовнішня БД) | 2–3 дні |
| Інтеграція з роботами/БП (смарт-процес) | 1–2 дні |
| Тестування та розгортання | 2–3 дні |
Всього для розділу середної складності: 1,5–2,5 тижня. Основна змінна — складність бізнес-логіки всередині розділу, а не сама інтеграція з Bitrix24.
На що звернути увагу
Додатки в iframe работают в ізольованому контексті. localStorage всередині iframe прив'язаний до домену вашого сервера, а не до домену портала. Якщо у вас кілька порталів-клієнтів — зберігайте member_id у ключі сховища, щоб не змішувати дані.
Токен AUTH_ID живе 1 годину. Для довгих сесій реалізуйте автооновлення через REFRESH_ID — інакше користувач отримає помилку авторизації після години роботи в розділі без перезавантаження сторінки.