Зачем вообще менять интерфейс коробочного Битрикс24
У коробочной версии Битрикс24 есть одно принципиальное отличие от облака: система стоит на вашем собственном сервере, и вы не ограничены типовым набором настроек из панели управления. Кастомизация интерфейса коробочного Битрикс24 — это не косметика ради красоты, а способ убрать из работы сотрудников лишние клики, скрыть неиспользуемые модули и вывести на видное место именно те данные, с которыми менеджер, бухгалтер или снабженец сталкивается каждый день. Когда в компании 40-60 человек и у каждого отдела свой процесс, типовая карточка сделки или лида быстро превращается в длинную простыню полей, половина которых конкретному сотруднику не нужна никогда.
Доработка интерфейса CRM в коробочной версии решает две задачи одновременно. Во-первых, она снижает сопротивление сотрудников при внедрении: люди охотнее пользуются системой, где всё нужное есть на первом экране. Во-вторых, она закрывает специфику бизнеса, которую типовая CRM в принципе не предусматривает: отраслевые поля, нестандартные статусы сделок, интеграции с внутренними учётными системами. У облачной версии Битрикс24 такой свободы нет: там можно менять оформление и добавлять пользовательские поля, но нельзя трогать ядро платформы и разворачивать локальные модули с прямым доступом к базе данных.
Что можно поменять без единой строчки кода
Прежде чем звать разработчика, стоит понять, какая часть кастомизации битрикс24 коробка закрывается штатными средствами администратора. Первый уровень — это визуальное оформление: логотип компании, цветовая схема портала, состав и порядок разделов в левом меню можно настроить прямо из панели управления, без привлечения программиста. Это решает задачу брендирования, но не меняет логику работы карточек и процессов.
Второй уровень — пользовательские поля в CRM. Добавлять их могут администраторы портала и сотрудники с правом изменять настройки CRM: путь в интерфейсе — CRM → Ещё → Настройки → Настройки CRM → Настройки форм и отчётов → Пользовательские поля. Поле можно привязать к любой сущности CRM (лиду, сделке, контакту, компании, счёту), задать тип (строка, список, дата, привязка к справочнику, файл), обязательность и видимость на разных стадиях воронки. Ограничение по количеству довольно щедрое — до 1016 пользовательских полей на каждый тип элемента CRM, так что для большинства задач это не станет узким местом. Именно с пользовательских полей стоит начинать любую доработку интерфейса: часто оказывается, что «нестандартная потребность» отдела продаж закрывается за 15 минут в админке, а не за неделю разработки.
Третий уровень — автоматизация без программирования через встроенный дизайнер бизнес-процессов. Это визуальный редактор с механикой drag-and-drop: администратор перетаскивает блоки условий и действий на холст, соединяет их стрелками и получает сценарий вроде «если сделка провисела в статусе «Согласование» больше трёх дней, поставить задачу руководителю отдела и отправить уведомление в чат». В коробочной версии дизайнер бизнес-процессов доступен в старших редакциях продукта и позволяет автоматизировать типовые управленческие сценарии, не трогая код и не рискуя сломать типовое обновление системы.
Типичные сценарии доработки интерфейса по отделам
Полезно смотреть на кастомизацию не как на абстрактную «доработку CRM», а как на набор конкретных запросов от разных отделов: тогда сразу видно, какой инструмент под какую задачу подходит. Отдел продаж чаще всего просит убрать из карточки сделки поля, которые нужны бухгалтерии, но мешают менеджеру, и добавить взамен блок с историей звонков и последними комментариями клиента наверху карточки, а не в конце длинной страницы. Это закрывается настройкой видимости пользовательских полей и перестановкой блоков в карточке, без разработки.
Отдел снабжения и склад обычно упираются в то, что типовая CRM вообще не рассчитана на складскую логику: нужны остатки, сроки поставки, привязка к конкретному производителю или партии. Здесь без пользовательских полей и, как правило, локального модуля с интеграцией к учётной системе не обойтись: сама CRM таких данных не хранит. Бухгалтерия и финансовый блок чаще просят автоматические уведомления и цепочки согласования: например, чтобы счёт на крупную сумму не проходил дальше без визы финансового директора. Это типовая задача для дизайнера бизнес-процессов: она решается визуальной схемой, а не кодом.
Руководству обычно нужен не интерфейс отдельной карточки, а сводная картина: дашборд по воронке продаж, просроченным задачам, загрузке сотрудников. В коробочной версии для таких задач можно как использовать штатные отчёты и BI-инструменты платформы, так и заказывать отдельный модуль с собственной аналитической панелью, если стандартной визуализации недостаточно для конкретных управленческих метрик компании. Разложив запросы отделов по этим четырём категориям ещё до старта проекта, интегратор сразу видит, где хватит пары часов настройки, а где потребуется техническое задание на разработку.
Локальные приложения: доработка на уровне ядра
Когда штатных настроек не хватает, например, нужна нетиповая логика расчёта, специфичный виджет в карточке сделки или интеграция с внутренней учётной системой предприятия, в дело идут локальные приложения. Это специально написанный программный модуль, который устанавливается на сервер клиента и получает прямой доступ к ядру платформы. В отличие от решений из Маркетплейса, которые создаются как тиражируемый продукт для множества порталов и общаются с системой только через REST API, локальное приложение пишется под одну конкретную компанию и может встраиваться гораздо глубже, вплоть до добавления собственных обработчиков событий, полей в базе данных и разделов административной панели.
Это самый мощный, но и самый рискованный инструмент кастомизации. Прямая доработка ядра платформы без соблюдения принятых практик разработки (то есть без вынесения кастомного кода в отдельный модуль) означает, что при следующем плановом обновлении коробочной версии изменения могут быть затёрты или конфликтовать с новым кодом ядра. Правильный подход — использовать события (обработчики), переопределение шаблонов компонентов и отдельные локальные модули, а не редактировать файлы ядра напрямую. Это требует более высокой квалификации разработчика на старте, зато доработка переживает обновления системы без переделки с нуля.
REST API и вебхуки: когда систему нужно связать с внешним миром
Отдельный класс задач — не изменение самого интерфейса Битрикс24, а его связь с другими системами компании: сайтом, складской программой, телефонией, внешней аналитикой. Здесь на первый план выходит REST API. В коробочной версии есть возможность, недоступная в облаке: можно добавлять собственные методы REST API, а не только пользоваться готовым набором. Делается это через регистрацию обработчика события OnRestServiceBuildDescription модуля rest: он возвращает структуру с именами области видимости (scope) и методов, к каждому из которых привязан свой обработчик. Это позволяет, например, отдать внешней системе не разрозненные стандартные вызовы, а один метод, который сразу возвращает нужный бизнесу срез данных.
Работа с кастомными методами REST API особенно оправдана, когда внешней системе не нужен весь массив данных портала, а нужен один конкретный срез, собранный из нескольких стандартных сущностей CRM сразу, например объединённая карточка клиента со сделками, счетами и последними активностями за один вызов вместо пяти-шести отдельных запросов к типовым методам. Это снижает нагрузку и на портал, и на внешнюю систему, а главное, переносит логику сборки данных туда, где она логично живёт: на сторону Битрикс24, а не на сторону каждой внешней интеграции по отдельности.
Для более простых сценариев интеграции штатных инструментов обычно достаточно. Входящий вебхук выдаёт постоянный ключ доступа для вызова методов REST API из внешнего сервиса: это удобно, когда сторонняя система должна писать данные в Битрикс24 (например, создавать лид из формы на сайте). Исходящий вебхук работает в обратную сторону: он отправляет данные во внешнюю систему при наступлении определённого события в самом Битрикс24, скажем, при смене стадии сделки. Оба инструмента находятся в разделе «Приложения → Ресурсы для разработчиков» и не требуют написания серверного кода со стороны Битрикс24. Код нужен только на принимающей или отправляющей стороне интеграции.
Как выбрать между настройкой, локальным приложением и интеграцией
На практике решение о способе доработки интерфейса CRM определяется тремя вопросами. Первый — можно ли закрыть задачу пользовательским полем, бизнес-процессом или настройкой прав доступа. Если да, не нужен ни один разработчик, всё делается силами администратора портала за часы, а не недели. Второй — требуется ли глубокая логика внутри самого портала: собственные разделы, нестандартные расчёты, изменение поведения стандартных сущностей CRM. Здесь нужен именно локальный модуль, и именно поэтому коробочная версия вообще существует как отдельный продукт: в облаке такой уровень доступа закрыт архитектурно. Третий вопрос — нужно ли просто передать данные между Битрикс24 и внешней системой без изменения интерфейса самого портала. Тогда правильный инструмент — REST API и вебхуки, а не доработка ядра.
Частая ошибка на этом этапе — заказывать локальную разработку там, где хватило бы пользовательского поля и бизнес-процесса, или наоборот — пытаться выжать сложную нетиповую логику из штатного дизайнера бизнес-процессов, хотя для неё нужен код. Разбор задачи по этим трём вопросам перед стартом работ экономит бюджет и сроки внедрения в разы. Мы в рамках услуги по Битрикс24 всегда начинаем именно с этого разбора: сначала смотрим, что закрывается настройками, и только затем переходим к разработке локальных модулей и интеграций, чтобы клиент не платил за код там, где достаточно администрирования.
Пример из практики
Показательный (иллюстративный) сценарий: производственная компания с отделом продаж и отдельным отделом снабжения работает в коробочном Битрикс24. Отделу снабжения нужно видеть в карточке сделки не типовой набор полей CRM, а остаток на складе и срок поставки от конкретного производителя (эти данные физически хранятся во внутренней учётной системе предприятия, а не в Битрикс24). Решение в такой ситуации обычно строится в два слоя: пользовательское поле в карточке сделки под отображение этих данных плюс небольшой локальный модуль, который по расписанию или по запросу подтягивает актуальные цифры из учётной системы через её собственный API и обновляет значение поля. Дизайнер интерфейса при этом не трогается вообще: карточка сделки выглядит как обычно, но с одним новым полем, которое реально экономит снабженцу время на переключение между системами. Такой подход — точечная доработка под конкретный процесс, а не масштабная перестройка интерфейса. Именно он обычно даёт наибольший эффект на вложенный бюджет.
Похожая логика применима практически к любому отделу, у которого есть собственная учётная система, не связанная с CRM изначально: сервисной службе с системой заявок, юридическому отделу с реестром договоров, отделу логистики со своей системой отслеживания доставок. Во всех этих случаях правильный порядок работы одинаковый: сначала фиксируется, какие именно данные нужны в интерфейсе Битрикс24 и с какой периодичностью они должны обновляться, и только потом принимается решение, достаточно ли периодической синхронизации через REST API или нужна более плотная интеграция на уровне локального модуля.
Что влияет на сроки и объём работ
Прежде чем закладывать бюджет на доработку интерфейса коробочного Битрикс24, стоит понимать, от чего реально зависят сроки. Первый фактор — глубина изменения: настройка пользовательского поля занимает минуты, дизайнер бизнес-процессов для типового сценария согласования — часы, а локальный модуль с интеграцией к внешней учётной системе — уже недели, потому что требует проектирования, написания кода, тестирования на копии портала и только затем переноса на боевую базу.
Второй фактор — состояние самого портала на момент старта. Если до этого в систему уже вносили правки напрямую в файлы ядра или ставили противоречащие друг другу решения из Маркетплейса, часть времени уйдёт не на новую доработку, а на приведение текущей конфигурации в порядок, чтобы новый код не конфликтовал со старым. Третий фактор — редакция коробочной версии: часть функциональности, например дизайнер бизнес-процессов, доступна только в старших редакциях продукта, и если компания работает на младшей редакции, в оценку стоит закладывать вопрос об апгрейде лицензии отдельно от вопроса о самой доработке.
Четвёртый фактор, который часто недооценивают, — количество интеграций, завязанных на портал. Каждая внешняя система, обменивающаяся данными с Битрикс24 через REST API или вебхуки, — это дополнительная точка, которую нужно учитывать при любом изменении логики карточек или структуры данных, иначе доработка интерфейса для одного отдела рискует незаметно сломать интеграцию, которой пользуется другой.
На что обратить внимание при планировании доработки
Перед тем как отдавать техническое задание в разработку, стоит зафиксировать несколько вещей. Нужно чётко описать, какая роль сотрудника видит какие поля и разделы, иначе доработанный интерфейс быстро зарастёт полями, нужными только одному отделу, но видимыми всем. Стоит заранее определить, где проходит граница между «это делаем настройкой» и «это делаем кодом»: это экономит время на этапе оценки. И обязательно нужно учитывать совместимость с будущими обновлениями коробочной версии: кастомный код должен жить в отдельных модулях и обработчиках событий, а не в теле файлов ядра, иначе каждое обновление превращается в риск потерять доработки или получить конфликт версий.
Отдельно стоит закладывать время на тестирование доработок на копии портала, а не сразу на боевой базе, особенно если речь о локальных модулях с доступом к ядру. Ошибка в обработчике события, который срабатывает при создании сделки, может затронуть весь процесс продаж компании, а не только один интерфейсный элемент. Именно поэтому для доработок уровня локальных приложений разумно привлекать интегратора с опытом именно коробочных инсталляций Битрикс24, а не только облачных проектов: архитектура и риски здесь заметно отличаются.
Не менее важно фиксировать доработки документально: какой модуль что делает, на какие события подписан, с какими внешними системами связан. Через год-два, когда за проект отвечает уже другой сотрудник или другой подрядчик, отсутствие такой документации превращается в отдельную статью расходов: приходится заново разбираться в логике каждого локального модуля методом чтения кода, вместо того чтобы открыть готовое описание. Для компании, которая планирует развивать портал не разово, а постоянно, эта дисциплина окупается уже на второй-третьей итерации доработок.
Частые вопросы
Можно ли доработать интерфейс коробочного Битрикс24 своими силами, без разработчика?
Значительную часть задач (оформление, пользовательские поля, автоматизацию через дизайнер бизнес-процессов) администратор портала настраивает самостоятельно. Разработчик нужен, когда требуется собственная логика внутри ядра платформы, нестандартные разделы или интеграция через кастомные методы REST API.
Чем локальное приложение отличается от решения из Маркетплейса Битрикс24?
Решение из Маркетплейса — тиражируемый продукт, который взаимодействует с порталом через REST API и работает одинаково на любой инсталляции. Локальное приложение пишется под конкретный портал, устанавливается на сервер клиента и может получать прямой доступ к ядру платформы, а значит, встраиваться значительно глубже.
Сколько пользовательских полей можно добавить в карточку сделки или лида?
Лимит — до 1016 пользовательских полей на каждый тип элемента CRM (лид, сделка, контакт, компания, счёт и так далее), так что для подавляющего большинства задач ограничение не станет препятствием.
Ломается ли кастомизация при обновлении коробочной версии Битрикс24?
Если доработка сделана правильно, то есть через отдельные модули, обработчики событий и переопределение шаблонов компонентов, без прямого редактирования файлов ядра, обновления проходят без потери изменений. Риск возникает именно тогда, когда код вносится напрямую в файлы ядра платформы.
Можно ли добавить в Битрикс24 коробку собственные методы REST API, а не только стандартные?
Да, это одна из возможностей, которой нет в облачной версии. Кастомные методы регистрируются через обработчик события OnRestServiceBuildDescription модуля rest, что позволяет отдавать внешним системам данные в удобной для конкретного бизнеса структуре.