Логотипbitrix-code
Разработка

Кастомизация интерфейса Битрикс24: вкладки, виджеты и встройки BX24.js

Дмитрий Горохов8 мин

Введение: когда стандартный интерфейс мешает продажам

Кастомизация интерфейса Битрикс24 — это способ подогнать портал под реальный процесс компании, а не наоборот. Менеджеры не должны запоминать, куда кликать: вкладки с нужными полями, виджеты с контекстной информацией и кастомные кнопки существенно сокращают время работы с карточкой сделки.

Стандартный интерфейс хорош для старта, но каждая компания работает по своим правилам. Менеджер дистрибьютора смотрит в карточку сделки на остатки и задолженность, логист — на статусы рейсов, а подрядчик — на график работ. Заставлять всех пользоваться «голым» порталом — значит добровольно терять часы рабочего времени каждую неделю.

В этой статье разберём, какие инструменты встройки даёт платформа: пользовательские вкладки, виджеты на JS, BX24.js-встройки и кастомные кнопки. Отдельно сравним облако и коробку — у них очень разные границы возможностей, и от этого зависит, как проектировать решение. Материал будет полезен CTO, IT-лидам и разработчикам.

Оглавление

Пользовательские вкладки: расширяем карточку 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 — незаметная зависимость от старой сущности может «потушить» целый сценарий после переезда.

Чек-лист перед запуском встройки

  1. Определена бизнес-задача: что именно ускоряет встройка и на сколько — измеримо, не «будет удобнее».
  2. Выбран правильный механизм: вкладка, виджет, кнопка или смарт-процесс — а не «всё сразу».
  3. Проверены права доступа для всех ролей, включая те, кому элемент не должен быть виден.
  4. Нагрузочное тестирование при массовом открытии карточек — узкое место найдено до пользователей.
  5. Резервный сценарий: портал работает, даже если встройка лежит или внешняя система недоступна.
  6. Версионирование и документация по поддержке: кто, что и зачем написал.

Вывод

  • Кастомизация интерфейса Битрикс24 — вкладки, виджеты, кнопки — даёт измеримый эффект: меньше времени на карточку, меньше ошибок менеджеров, полнее заполненные поля.
  • Облако закрывает типовые сценарии через REST и BX24.js; коробка снимает любые ограничения, вплоть до вёрстки и структуры меню.
  • Клиентский код должен показывать, а не вычислять: вся бизнес-логика — на сервере, иначе поддержка превратится в кошмар.
  • Встройки нужно проектировать как продукт: права, кеш, логи, тесты, план поддержки и владелец внутри компании.
  • Начинайте с одной вкладки или кнопки на самом частом сценарии — и масштабируйте по измеренному эффекту, а не по пожеланиям.

FAQ

Можно ли кастомизировать интерфейс облачного Битрикс24?

Да — пользовательские вкладки, виджеты, кнопки и смарт-процессы доступны и в облаке. Недоступны только изменение шаблонов и вёрстки стандартных страниц, а также подключение произвольного JS на всех экранах.

Нужен ли сервер для виджетов на BX24.js?

Для чтения данных из CRM — нет, JS-библиотека вызывает REST напрямую из браузера. Для серьёзных сценариев — обращения к 1С, ЭДО и другим системам — сервер обязателен: выполняются они серверной частью приложения, в браузере остаётся только отображение.

Сломается ли встройка после обновления платформы?

При использовании штатных механизмов — REST, виджеты, смарт-процессы — риск минимален. Нестандартные хуки и подмена шаблонов в коробке требуют регрессионной проверки после обновлений, лучше закладывать её в регламент.

Как понять, что выбрать: вкладку, виджет или кнопку?

Ориентируйтесь на частоту обращения к информации. Редко нужный, но объёмный контекст — во вкладку; постоянный показатель — в виджет или поле; разовое действие — в кнопку. Если сомневаетесь, начните с кнопки: это самый дешёвый и обратимый вариант.

Сколько стоит кастомизация интерфейса?

Простая вкладка с данными из внешней системы — работа на несколько дней; комплексное рабочее место с калькуляторами и интеграциями — проект на месяц и дольше. Смета всегда зависит от числа сценариев и систем-источников, поэтому мы начинаем с аудита процесса.

Хотите вкладку или виджет, который закроет ваш сценарий? Напишите нам — разберём требования и предложим архитектуру встройки.