Разработка кастомных разделов Битрикс24

Разработка кастомных разделов Битрикс24

Стандартные разделы Битрикс24 — CRM, Задачи, Диск — покрывают типовые сценарии. Но когда бизнесу нужен раздел «Заявки на закупку» с собственной логикой согласования, маршрутизацией по ролям и кастомным UI — встроенных инструментов не хватает. Универсальные списки и смарт-процессы решают часть задач, но упираются в ограничения интерфейса. Здесь начинается разработка кастомного раздела.

Архитектура кастомного раздела

Кастомный раздел в Битрикс24 — это приложение, встроенное в левое меню портала через механизм placement. Технически это SPA, загружаемое в iframe внутри интерфейса Б24. Регистрация происходит через REST API метод placement.bind с типом LEFT_MENU.

Точка входа — файл, отдаваемый вашим сервером (или серверлесс-функцией). Битрикс24 загружает его в iframe, передавая параметры авторизации: AUTH_ID, REFRESH_ID, member_id. Через эти параметры приложение получает доступ к REST API портала.

BX24.init(function() {
    BX24.callMethod('user.current', {}, function(result) {
        // Текущий пользователь для проверки прав
    });
});

Ключевое решение на старте: где хранить данные раздела — в сущностях Битрикс24 (смарт-процессы, списки) или во внешней БД. От этого зависит всё остальное.

Вариант 1: данные в смарт-процессах

Смарт-процессы (\Bitrix\Crm\Service\Factory) — это конструктор CRM-сущностей. Создаёте тип через CRM → Настройки → Автоматизация → Смарт-процессы, добавляете пользовательские поля, настраиваете воронку. Данные хранятся в таблицах b_crm_dynamic_items_*.

Кастомный раздел в этом случае — альтернативный UI для работы с данными смарт-процесса. Вместо стандартной карточки и канбана вы рисуете свой интерфейс, а данные читаете и пишете через REST:

• crm.item.list — получение списка элементов
• crm.item.add / crm.item.update — создание и обновление
• crm.item.fields — метаданные полей

Преимущество: бесплатно получаете воронки, роботов, бизнес-процессы, права доступа, историю изменений. Ограничение: REST API отдаёт максимум 50 элементов за запрос, для больших списков нужна пагинация. При 10 000+ записей интерфейс должен реализовать серверную фильтрацию.

Вариант 2: внешняя БД

Когда данные сложнее, чем плоский список с полями — связи многие-ко-многим, иерархии, специфические индексы — проще хранить во внешней PostgreSQL или MySQL. Кастомный раздел обращается к вашему бэкенду по API, а с Битрикс24 взаимодействует только для авторизации и получения контекста пользователя.

Схема: iframe загружает SPA → SPA проверяет AUTH_ID через oauth.bitrix.info/rest/ → получает user_id → запрашивает данные с вашего бэкенда по user_id.

Преимущество: нет лимитов REST API, полный контроль над структурой данных. Ограничение: теряете встроенные роботов и бизнес-процессы, права доступа нужно реализовать самостоятельно.

Интеграция с интерфейсом Б24

Для ощущения нативности кастомный раздел должен использовать дизайн-систему Битрикс24. Официальный 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 — пользователей подразделения.

Оценка сроков

Итого для раздела средней сложности: 1.5–2.5 недели. Основная переменная — сложность бизнес-логики внутри раздела, а не сама интеграция с Битрикс24.

На что обратить внимание

Iframe-приложения работают в изолированном контексте. localStorage внутри iframe привязан к домену вашего сервера, а не к домену портала. Если у вас несколько порталов-клиентов — храните member_id в ключе storage, чтобы не смешивать данные.

Токен AUTH_ID живёт 1 час. Для долгих сессий реализуйте автообновление через REFRESH_ID — иначе пользователь получит ошибку авторизации после часа работы в разделе без перезагрузки страницы.