Кастомизация интерфейса Битрикс24: вкладки, виджеты и встройки BX24.js
Введение: когда стандартный интерфейс мешает продажам
Кастомизация интерфейса Битрикс24 — это способ подогнать портал под реальный процесс компании, а не наоборот. Менеджеры не должны запоминать, куда кликать: вкладки с нужными полями, виджеты с контекстной информацией и кастомные кнопки существенно сокращают время работы с карточкой сделки.
Стандартный интерфейс хорош для старта, но каждая компания работает по своим правилам. Менеджер дистрибьютора смотрит в карточку сделки на остатки и задолженность, логист — на статусы рейсов, а подрядчик — на график работ. Заставлять всех пользоваться «голым» порталом — значит добровольно терять часы рабочего времени каждую неделю.
В этой статье разберём, какие инструменты встройки даёт платформа: пользовательские вкладки, виджеты на JS, BX24.js-встройки и кастомные кнопки. Отдельно сравним облако и коробку — у них очень разные границы возможностей, и от этого зависит, как проектировать решение. Материал будет полезен CTO, IT-лидам и разработчикам.
Оглавление
- Пользовательские вкладки: расширяем карточку CRM
- Виджеты на JavaScript и BX24.js
- Кастомные кнопки и действия в карточке
- Облако против коробки: что где можно
- Ограничения, безопасность и поддержка
- Чек-лист перед запуском встройки
- Вывод
- FAQ
Пользовательские вкладки: расширяем карточку CRM
Самый простой уровень кастомизации интерфейса Битрикс24 — пользовательские вкладки в карточке лида, сделки, контакта и компании. Типовой сценарий: заказчику нужно показывать в сделке данные из внешней системы — например, остатки на складах из 1С или историю оплат из биллинга.
Вкладка загружается в iframe и получает контекст (ID сущности) через параметры URL. Серверная часть встройки ходит в Битрикс по REST и возвращает готовый HTML или данные для клиентского рендера. В одном из наших проектов такая вкладка вывела производственный график в карточку сделки, и менеджеры перестали держать вторую вкладку с внешней системой — экономия составила около получаса в день на сотрудника.
Когда вкладка уместна, а когда нет
Вкладка — правильный выбор, когда информация объёмная, редко меняется внутри сессии и не нужна при каждом взгляде на карточку. Если данные нужны постоянно (например, долг клиента), лучше виджет в саму карточку или пользовательское поле, заполняемое автоматически. Ошибка, которую мы регулярно видим в чужих проектах, — десяток вкладок в одной карточке: в результате менеджер не находит и стандартные.
На что обратить внимание
- Вкладки грузятся при каждом открытии карточки — кешируйте запросы к внешней системе и отдавайте данные быстро, иначе встройка будет тормозить весь интерфейс.
- Не дублируйте стандартные поля: вкладка — для контекста, которого нет в CRM.
- Соблюдайте эстетику: интерфейс встройки должен выглядеть как часть портала, а не как сторонняя страница из 2010 года.
- Продумайте поведение при недоступности внешней системы — вкладка должна показывать аккуратную заглушку, а не таймаут.
Виджеты на JavaScript и BX24.js
Виджеты — это встройки, которые встраиваются непосредственно в страницу: в карточку CRM, в список сделок или в левое меню. Клиентская часть пишется на JavaScript с использованием BX24.js — JS-библиотеки, которая отдаёт методы работы с REST прямо из браузера, без необходимости поднимать промежуточный сервер для простых операций.
Типовые кейсы: калькулятор стоимости в карточке сделки, индикатор скоринговой оценки клиента, кнопка быстрого создания связанных задач. BX24.js умеет звать REST-методы портала, подписываться на события карточки и вызывать нативные диалоги — то есть встройка ощущается пользователю как штатный элемент интерфейса.
Минимальный пример BX24.js
// Чтение полей сделки из виджета
BX24.callMethod("crm.deal.get", { id: 125 }, function(res) {
if (res.error()) {
console.error("Ошибка REST:", res.error());
return;
}
const deal = res.data();
console.log("Сумма сделки:", deal.OPPORTUNITY);
});
// Выполняемся в контексте iframe, размер подгоняем автоматически
BX24.fitWindow();
Важный нюанс: виджеты исполняются в браузере пользователя. Критичные операции — запись в CRM, обращение к 1С, расчёты с бизнес-логикой — переносите на сервер: клиент должен только показывать результат и отправлять команды. Иначе вы получаете неуправляемое распределённое приложение, которое невозможно отладить.
UX-риски виджетов
- Слишком много виджетов в одной карточке раздувает страницу и удлиняет её отрисовку.
- Асинхронная загрузка данных должна сопровождаться индикаторами, иначе менеджеры кликают «туда, где ещё ничего нет».
- Любые действия виджета должны логироваться на сервере — по вопросу «кто нажал кнопку» в спорах с клиентами приходится отвечать регулярно.
Кастомные кнопки и действия в карточке
Кастомные кнопки — самый заметный для пользователей приём кастомизации. Кнопка «Сформировать счёт», «Отправить в ЭДО» или «Проверить клиента» убирает из процесса ручные действия и снижает долю ошибок: менеджеру больше не нужно помнить порядок операций.
Реализуется через смарт-процессы, бизнес-процессы или кастомный виджет, добавляющий кнопку на панель действий. Для коробки доступен ещё один уровень — модификация шаблонов компонентов, где кнопки и обработчики прописываются прямо в коде. Подробно про программную модель расширения ядра мы писали в обзоре D7 ORM.
Типовые сценарии кнопок
- Документы: формирование счёта, договора или КП из шаблона с данными карточки.
- Интеграции: отправка сделки в учётную систему, запуск синхронизации с 1С.
- Проверки: скоринг, сверка реквизитов по внешним сервисам перед переходом на следующий этап.
Что важно предусмотреть
- Права доступа: кнопка не должна появляться там, где действие пользователю недоступно.
- Обратная связь: индикатор выполнения и понятное сообщение об успехе или ошибке.
- Идемпотентность: повторный клик не должен создавать дубли документов.
- Контроль статуса: кнопка недоступна, пока предыдущая операция не завершена.
Облако против коробки: что где можно
Главное различие — граница дозволенного. В облаке вы живёте в рамках REST API и стандартных механизмов встройки. В коробке любой интерфейс можно поменять до уровня вёрстки, подключать свои JS-библиотеки на всех страницах и менять поведение стандартных компонентов.
| Возможность | Облако | Коробка |
|---|---|---|
| Пользовательские вкладки | Да | Да |
| Виджеты на BX24.js | Да | Да |
| Кастомные кнопки | Ограниченно (REST, процессы) | Да, включая PHP-обработчики |
| Изменение шаблонов и вёрстки | Нет | Да |
| Кастомные сущности и поля | Смарт-процессы | Смарт-процессы + Highload-блоки |
| Свои JS-библиотеки на всех страницах | Нет | Да |
| Изменение левого меню и структуры разделов | Нет | Да |
Практический вывод: типовые потребности отдела продаж закрываются облаком. Если же интерфейс — часть конкурентного преимущества (встраивание отраслевых справочников, свои списки с нестандартной вёрсткой, интеграция с рабочим местом оператора), нужна коробочная версия Битрикс24. Для компаний без собственной IT-команды разумнее начать с облачного внедрения и типовых механизмов.
Ограничения, безопасность и поддержка
Кастомизация — это код, а код требует сопровождения. В нашей практике чаще всего приходится разбирать встройки, сделанные «на коленке»: без версионирования, с захардкоженными токенами и синхронными запросами, убивающими портал при двухстах одновременных открытиях карточки. Дёшево написать — дорого поддерживать.
Хорошее правило: встройка должна пережить обновление платформы без правок и отвечать быстрее, чем открывается карточка.
- Храните токены приложения на сервере, а не в JS, доступном любому открывшему карточку пользователю.
- Ограничивайте область встройки конкретными сущностями и разделами — чем шире охват, тем выше риск побочных эффектов.
- Покрывайте REST-обработчики тестами и логируйте ошибки с контекстом.
- Закладывайте кастомный интерфейс в регламент поддержки — например, как при разработке кастомных модулей.
- Договоритесь с бизнесом о владельце встройки: без ответственного внутри компании интерфейсная доработка быстро устаревает.
Если предстоит переезд портала, все встройки должны быть учтены в плане миграции Битрикс24 — незаметная зависимость от старой сущности может «потушить» целый сценарий после переезда.
Чек-лист перед запуском встройки
- Определена бизнес-задача: что именно ускоряет встройка и на сколько — измеримо, не «будет удобнее».
- Выбран правильный механизм: вкладка, виджет, кнопка или смарт-процесс — а не «всё сразу».
- Проверены права доступа для всех ролей, включая те, кому элемент не должен быть виден.
- Нагрузочное тестирование при массовом открытии карточек — узкое место найдено до пользователей.
- Резервный сценарий: портал работает, даже если встройка лежит или внешняя система недоступна.
- Версионирование и документация по поддержке: кто, что и зачем написал.
Вывод
- Кастомизация интерфейса Битрикс24 — вкладки, виджеты, кнопки — даёт измеримый эффект: меньше времени на карточку, меньше ошибок менеджеров, полнее заполненные поля.
- Облако закрывает типовые сценарии через REST и BX24.js; коробка снимает любые ограничения, вплоть до вёрстки и структуры меню.
- Клиентский код должен показывать, а не вычислять: вся бизнес-логика — на сервере, иначе поддержка превратится в кошмар.
- Встройки нужно проектировать как продукт: права, кеш, логи, тесты, план поддержки и владелец внутри компании.
- Начинайте с одной вкладки или кнопки на самом частом сценарии — и масштабируйте по измеренному эффекту, а не по пожеланиям.
FAQ
Можно ли кастомизировать интерфейс облачного Битрикс24?
Да — пользовательские вкладки, виджеты, кнопки и смарт-процессы доступны и в облаке. Недоступны только изменение шаблонов и вёрстки стандартных страниц, а также подключение произвольного JS на всех экранах.
Нужен ли сервер для виджетов на BX24.js?
Для чтения данных из CRM — нет, JS-библиотека вызывает REST напрямую из браузера. Для серьёзных сценариев — обращения к 1С, ЭДО и другим системам — сервер обязателен: выполняются они серверной частью приложения, в браузере остаётся только отображение.
Сломается ли встройка после обновления платформы?
При использовании штатных механизмов — REST, виджеты, смарт-процессы — риск минимален. Нестандартные хуки и подмена шаблонов в коробке требуют регрессионной проверки после обновлений, лучше закладывать её в регламент.
Как понять, что выбрать: вкладку, виджет или кнопку?
Ориентируйтесь на частоту обращения к информации. Редко нужный, но объёмный контекст — во вкладку; постоянный показатель — в виджет или поле; разовое действие — в кнопку. Если сомневаетесь, начните с кнопки: это самый дешёвый и обратимый вариант.
Сколько стоит кастомизация интерфейса?
Простая вкладка с данными из внешней системы — работа на несколько дней; комплексное рабочее место с калькуляторами и интеграциями — проект на месяц и дольше. Смета всегда зависит от числа сценариев и систем-источников, поэтому мы начинаем с аудита процесса.
Хотите вкладку или виджет, который закроет ваш сценарий? Напишите нам — разберём требования и предложим архитектуру встройки.
bitrix