Вернуться к статьям Типовые задачи под словом «доработка» включают: добавить обязательное поле в сделке, собрать маршрут согласования, подключить внешнюю систему, вывести сотруднику отдельную вкладку или обработать большой поток данных. Для них нужны разные инструменты, а поддержка и риски тоже будут разными.
Способ изменения выбирают после того, как понятны требования к процессу. Одну задачу можно закрыть штатными полями, стадиями и роботами, для другой достаточно приложения из Маркетплейса. Если нужен обмен с внешней системой без нового интерфейса, рассматривают REST-интеграцию через вебхук. Собственное приложение оценивают там, где стандартного интерфейса и сценариев Битрикс24 недостаточно.
Как определить способ доработки Битрикс24
Сначала ответьте на пять вопросов о процессе.
| Вопрос | Что нужно зафиксировать | На что влияет ответ |
|---|---|---|
| Какие данные нужны | Новые поля, документы, справочники, связи между сущностями | Штатная CRM-сущность, смарт-процесс или отдельная модель данных |
| Кто работает с процессом | Роли, подразделения, внешние пользователи, мобильные сотрудники | Права, интерфейс, маршрут передачи работы |
| Что запускает действие | Смена стадии, заполнение поля, входящее событие, расписание | Роботы, триггеры, вебхук, серверный обработчик |
| Есть ли внешняя система | 1С, сайт, телефония, склад, сервис проверки контрагентов, внутренний сервис | Готовый коннектор, REST-интеграция или приложение |
| Что происходит при ошибке | Повтор запроса, уведомление, журнал, ручная корректировка, запрет дублей | Нужны ли очередь, фоновая обработка и собственный код |
В Битрикс24 можно добавлять пользовательские поля, настраивать стадии, роли, роботов и смарт-процессы. Доступность отдельных возможностей зависит в том числе от тарифа и прав пользователя.
Если процесс укладывается в карточку, этап, ответственного и действие при смене стадии, стоит проверить штатную настройку. Отдельный экран, сложный расчёт или обмен с несколькими системами требуют оценки готового приложения, REST-интеграции или собственной разработки.
Когда достаточно штатной настройки Битрикс24
Штатная настройка подходит, если процесс укладывается в существующие сущности CRM, а администратор портала сможет поддерживать его без изменения кода.
Обычно используют:
- поля и разделы карточки;
- воронки и стадии;
- права CRM;
- роботов и триггеры;
- смарт-процессы;
- штатные списки, представления и уведомления.
Смарт-процесс нужен, когда задаче тесно в сделке, лиде или счёте. Типовой сценарий: рекламация, сервисное обращение, внутреннее согласование или заявка на закупку. Для такой работы можно создать отдельную сущность со своей карточкой, стадиями, правами и роботами.
Чек-лист: можно ли обойтись настройкой CRM
Проверьте следующие условия:
- [ ] Данные можно хранить в сделке, лиде, компании, контакте или смарт-процессе.
- [ ] Сотрудникам хватает стандартной карточки, списка, канбана и фильтров.
- [ ] Действие запускается стадией, полем, сроком или событием в CRM.
- [ ] Нужное действие есть среди доступных штатных роботов.
- [ ] Права настраиваются ролями CRM без отдельной модели доступа.
- [ ] Внешняя система не нужна либо для неё есть штатная или готовая интеграция.
- [ ] Логику процесса можно описать без длинной цепочки исключений.
Если не выполняются несколько условий, проверьте готовые приложения и интеграцию.
Когда роботы начинают мешать
Робот выполняет действие при попадании CRM-элемента на стадию. Если действие запускается переходом по стадии, робот подходит для этого сценария: создать задачу, отправить уведомление, запросить документ или поставить контроль.
Проблемы начинаются, когда критичный процесс собирают из длинной цепочки роботов с неочевидными условиями, задержками и обходными ветками. В такой схеме трудно понять, почему элемент не обработался, можно ли безопасно повторить действие, кто исправит ошибку и не создастся ли дубль.
Очередь, повторные попытки, подробный журнал ошибок и сложная проверка данных обычно выходят за пределы простой автоматизации роботами.
Когда стоит проверить готовое приложение в Маркетплейсе Битрикс24
Перед заказной разработкой проверьте Маркетплейс Битрикс24. Там представлены решения для телефонии, мессенджеров, доставки, проверки реквизитов, документов, отчётности и других типовых задач.
Готовое приложение может закрыть задачу без разработки с нуля. Проверьте приложение на реальном рабочем сценарии, а не только по описанию в каталоге.
| Что проверить | Почему это важно |
|---|---|
| Соответствие процессу | Функция может быть похожей, но не поддерживать нужные сущности, поля или порядок работы |
| Запрашиваемые права | Приложение получает доступ к данным и инструментам портала в пределах разрешений |
| Работа с внешним сервисом | Для части решений нужны API-ключи и отдельные условия работы с внешним поставщиком |
| Обновления и поддержка | Нужно понимать, кто разбирает проблему после изменений в портале или внешнем API |
| Экспорт и зависимость от поставщика | Полезно заранее определить порядок действий, если приложение перестанут использовать |
| Совместимость с текущими настройками | Решение не должно конфликтовать с полями, роботами и действующими интеграциями |
Типовой пример готового решения: приложение DaData для Битрикс24 добавляет вкладки в карточки CRM и роботов для бизнес-процессов. Для внешних сценариев понадобятся API-ключи DaData. Это пример готовой интеграции, а не рекомендация для любого портала.
Когда нужна REST-интеграция или вебхук Битрикс24
REST-интеграция нужна, когда Битрикс24 обменивается данными с внешней системой: сайтом, 1С, складской программой, сервисом расчётов или внутренним приложением.
Вебхук — упрощённый способ работы с REST в рамках одного портала. Он подходит для узких внутренних сценариев, если сотрудникам не нужен отдельный интерфейс внутри Битрикс24.
Признаки задачи для REST-интеграции
- данные передаются в одну или обе стороны;
- обработка запускается по событию или расписанию;
- отдельная вкладка, форма или отчёт в Битрикс24 не требуются;
- интеграция работает для одного портала;
- определено, от чьего имени выполняются операции и какие права нужны;
- есть внешний обработчик, который принимает события и вызывает REST API.
REST API работает от имени конкретного пользователя. Для авторизации используют постоянный код входящего вебхука, который хранится как секрет или OAuth 2.0. URL вебхука содержит секрет, поэтому его хранят конфиденциально.
Что предусмотреть в интеграции до запуска
| Риск | Что согласовать заранее |
|---|---|
| Дубли при повторной доставке | Идентификатор внешнего объекта и правило проверки перед созданием записи |
| Ошибка внешнего сервиса | Количество попыток, интервал повторов, ответственный за разбор ошибки |
| Большой объём данных | Пакетная обработка, пагинация, очередь и фоновый запуск |
| Потеря события | Журнал обмена и способ повторно обработать конкретную запись |
| Лишние права | Минимальный набор разрешений для вебхука или приложения |
| Изменение структуры данных | Версия формата, обязательные поля и порядок обновления интеграции |
В облачной версии Битрикс24 действуют ограничения интенсивности и ресурсоёмкости REST API, а продолжительность одного REST-запроса ограничена. Массовый обмен не стоит строить как один длинный запрос. Его разбивают на части, при необходимости выносят обработку в очередь и отдельно фиксируют ошибки.
Когда вебхука уже недостаточно
Вебхук удобен для простого сценария одного портала, но его не стоит делать основой сложной системы. Он не подходит для тиражного решения и не поддерживает часть методов, которым нужен контекст приложения.
Приложение или отдельный серверный сервис рассматривают, если интеграция должна работать с разными пользователями, управлять доступом, хранить собственное состояние, показывать интерфейс в портале или обрабатывать большой поток событий.
Когда нужна разработка собственного приложения Битрикс24
Собственное приложение оценивают, если требования нельзя надёжно закрыть настройкой или готовым решением.
Признаки, при которых стоит оценить собственное приложение:
- отдельная вкладка, форма, таблица, кнопка или отчёт в карточке CRM;
- специальный интерфейс для менеджера, техника, диспетчера или другого сотрудника;
- сложные расчёты и правила, которые трудно поддерживать набором роботов;
- серверная обработка событий;
- собственное состояние процесса вне CRM;
- очередь фоновых операций и контроль повторов;
- работа с несколькими внешними системами в одной цепочке;
- разграничение доступа, выходящее за штатный сценарий;
- необходимость установить решение на нескольких независимых порталах.
Приложение обычно использует REST API для работы с Битрикс24. В нём можно добавить интерфейс, OAuth 2.0, серверную логику и обработку событий.
Для внутреннего сценария одного заказчика подходит локальное приложение. Если решение нужно устанавливать на неограниченное число порталов, выбирают формат, рассчитанный на публикацию и установку в Маркетплейсе.
Варианты работ с вкладками, роботами, интеграциями и готовыми решениями описаны на странице разработки приложений Битрикс24.
Таблица выбора: настройка, приложение или REST-интеграция
| Требование | Штатная настройка | Готовое приложение | REST-интеграция или вебхук | Собственное приложение |
|---|---|---|---|---|
| Новые поля в карточке | Подходит | Иногда избыточно | Не требуется | Не требуется без особого интерфейса |
| Новая внутренняя сущность со стадиями | Подходит через смарт-процесс | Возможно, если сценарий типовой | Возможна связка с внешней системой | Нужно при сложной логике или UI |
| Уведомление при смене стадии | Подходит через робота | Обычно не нужно | Нужно, если уведомляет внешний сервис | Нужно при нестандартных правилах |
| Проверка реквизитов через внешний сервис | Возможна при наличии штатного решения | Часто подходит | Подходит для собственной связки | Нужно при специальном интерфейсе и логике |
| Обмен с 1С, сайтом или складом | Только при готовом коннекторе | Возможен | Основной вариант без отдельного UI | Нужен при сложной обработке, доступах или интерфейсе |
| Отдельная вкладка в сделке | Не подходит | Подходит, если функция уже есть | Не решает задачу интерфейса | Подходит |
| Мобильный рабочий экран для техников | Не подходит | Проверяется по готовым решениям | Не решает задачу интерфейса | Подходит |
| Массовая фоновая обработка | Ограниченно | Зависит от приложения | Возможна при очередях и контроле ошибок | Подходит при комплексном сценарии |
| Решение для одного портала | Подходит | Подходит | Подходит через вебхук или REST | Подходит как локальное приложение |
| Решение для многих независимых порталов | Не решает задачу распространения | Подходит, если продукт уже существует | Вебхук не подходит как тиражный формат | Нужен тиражный формат приложения |
Используйте таблицу как первый ориентир, затем проверьте данные, права, нагрузку и исключения. Перед выбором проверяют состав данных, права, интеграции, нагрузку и исключения.
Примеры границы между настройкой и разработкой
БК-ГРУПП: процесс собран преимущественно настройками
В кейсе БК-ГРУПП типовой поток обращений собрали в CRM с одной стандартной воронкой, подключением каналов коммуникации, интеграциями и роботами-уведомлениями. На странице кейса объём работ характеризуется как минимальные настройки.
Несколько каналов и уведомления сами по себе не требуют собственного приложения. Если стандартная воронка, карточки и доступные интеграции покрывают процесс, разработка будет избыточной.
3click: штатная CRM плюс код для специального сценария
В кейсе 3click сохранили штатные группы, смарт-процессы и задачи. Для части сценария добавили пользовательские поля, вкладку быстрого редактирования, обработчик приложения, робота и обмен с 1С.
В этом кейсе штатные сущности сохранили, а код добавили для отдельных сценариев: специального интерфейса, расчёта и обмена данными. Не требуется переписывать весь процесс, если нестандартная логика находится на конкретном участке.
McBrothers: приложение внутри сделки для работы техников
В кейсе McBrothers приложение внутри сделки создаёт задачу технику и подставляет данные по адресу, оборудованию и запчастям. Интерфейс адаптирован под мобильную работу.
В этом кейсе приложение потребовалось из-за отдельного интерфейса для сотрудников. Одного изменения полей или стадии сделки для такого сценария недостаточно.
Что подготовить для оценки доработки Битрикс24
По описанию процесса определяют работы, данные, исключения и границы интеграции.
Чек-лист для первичной оценки
- [ ] Схема процесса: с чего он начинается, какие есть этапы и чем заканчивается.
- [ ] Роли участников: кто создаёт запись, меняет данные, согласует и принимает результат.
- [ ] Примеры реальных карточек, документов и сообщений без секретов и персональных данных.
- [ ] Список полей: какие данные уже есть, какие нужно добавить и где будет источник истины.
- [ ] Перечень внешних систем и их владельцев.
- [ ] Направление обмена: Битрикс24 получает данные, передаёт их или делает оба действия.
- [ ] Частота и предполагаемый объём обмена.
- [ ] Исключения: отмена, повторная отправка, неполные данные, дубль, ручная корректировка.
- [ ] Требования к правам доступа.
- [ ] Требования к журналу ошибок и уведомлениям.
- [ ] Сценарии приёмки: входные данные, действие пользователя или системы, ожидаемый результат.
Если в процессе участвуют несколько отделов, интеграции и перенос данных, сначала спроектируйте общую схему, а не ограничивайтесь настройкой отдельных сущностей. Такой формат работ описан на странице внедрения Битрикс24.
Ошибки при выборе способа доработки
Заказывать код до проверки штатных возможностей
Новые поля, обязательность заполнения, стадии, доступы и отдельные внутренние сущности часто настраиваются без разработки. Проверьте карточки, смарт-процессы, роботов и права до того, как заказывать код.
Строить критичный процесс из непрозрачной цепочки роботов
Если в цепочке трудно найти источник ошибки или безопасно повторить действие, процесс становится зависимым от ручного разбора. Для сложной логики лучше выделить понятный сервис или приложение с журналом операций.
Выбирать приложение только по списку функций
У приложения может быть нужная функция, но другая модель прав, набор полей или порядок работы. Проверка на тестовом сценарии важнее совпадения названия в каталоге.
Считать URL вебхука достаточной защитой
Вебхук содержит секрет и действует в пределах выданных прав. Его нельзя размещать в комментариях задач, скриншотах, логах и публичных репозиториях. Права вебхука ограничивают минимально необходимым набором.
Не проектировать повторы и дубли
Внешняя система может повторно отправить событие, а обработчик — завершиться с ошибкой после частичного выполнения. Для интеграции нужны правила идемпотентности, идентификаторы объектов и порядок повторной обработки.
Запрашивать точную оценку без исключений
Формулировка «нужна интеграция с 1С» не описывает состав данных, направление обмена, права, расписание, ошибки и объём. Оценка появляется после разбора сценариев и границ ответственности.
FAQ по доработке Битрикс24
- Можно ли сначала настроить Битрикс24, а потом добавить приложение?
Да, если заранее определить модель данных и границы процесса. Можно собрать понятную часть на штатных сущностях, а затем добавить приложение там, где нужен особый интерфейс, расчёт или внешний обмен. Такой типовой гибридный подход использован в кейсе 3click.
- REST и приложение Битрикс24 — это разные альтернативы?
REST API — способ взаимодействия с данными и возможностями Битрикс24. Вебхук даёт упрощённый REST-доступ для одного портала. Приложение тоже использует REST, но может добавить OAuth-авторизацию, интерфейс, обработку событий и серверную логику.
- Всегда ли для интеграции нужна разработка с нуля?
Нет. Сначала проверяют штатные коннекторы и готовые приложения Маркетплейса. Разработка требуется, если готовое решение не покрывает критичные требования к данным, процессу, правам или обработке ошибок.
- Когда вместо сделки нужен смарт-процесс?
Смарт-процесс подходит, когда задаче нужна собственная карточка, стадии, поля, роли и маршрут, но она не относится к продаже. Типовой сценарий: рекламация, внутреннее согласование или сервисное обращение. Решение зависит от необходимости отдельной сущности, а не от названия процесса.
- Можно ли сделать сложную интеграцию через вебхук?
Вебхук может быть частью сложной схемы, но для неё отдельно проектируют права, хранение секретов, повторные попытки, дубли, журнал ошибок и ограничения API. Если нужен интерфейс внутри Битрикс24, работа разных пользователей или тиражирование решения, одного вебхука обычно недостаточно.
- Нужна ли коробочная версия Битрикс24 для собственной разработки?
Облачная версия поддерживает REST, вебхуки и приложения. Выбор между облаком и коробкой зависит не только от задачи кастомизации, но и от требований к инфраструктуре, обновлениям, нагрузке и эксплуатации. Без отдельного сравнения общий вывод делать нельзя.
Заключение
Поля, стадии, права, роботы и смарт-процессы закрывают многие внутренние задачи. Для типового внешнего сценария может подойти готовое приложение. REST-интеграция нужна для обмена данными без отдельного интерфейса. Собственное приложение оценивают при необходимости специального экрана, серверной логики, обработки событий, фоновых операций или нестандартного управления доступом.
При оценке сразу определите результат и способ его проверки: схему процесса, роли, данные, внешние системы, исключения и сценарии приёмки. Так объём работ становится конкретнее, чем при общей формулировке «доработка», и можно выбрать минимально достаточный способ реализации.