Битрикс24: как сделать свое активити
Парадокс автоматизации: чем больше бизнес-процессов вы строите, тем заметнее, что стандартных кирпичиков не хватает. И тогда начинаются костыли — цепочки из 8–12 роботов, дубляж полей, лишние вебхуки. Работает? Да. Но ломается в самый неудобный момент.
Смелый вопрос: где заканчивается «соберу из того, что есть», и начинается нормальное своё активити? Разберёмся без фанатизма, но и без иллюзий. И покажу, как подойти к теме так, чтобы не превратить CRM в карточный домик.
Своё активити или костыли: где проходит граница
Граница простая: повторяемость + сложность = кандидат на отдельный блок. Если вы трижды в разных воронках собираете один и тот же пазл из роботов, который шлёт запрос во внешний сервис, ждёт ответ, парсит, валидирует и пишет комментарий — это не «гибкость». Это техдолг.
Микро-сценарий. Отдел продаж каждый день тянет статусы доставки из курьерки. Без отдельного действия набирается 7 шагов: таймер, вебхук, ожидание, разбор ответа, ветвление, запись полей, уведомление. Один сбой — и вся воронка висит на «Ожидании». Своё активити в Битрикс24 сворачивает этот «гармошку-скрипт» в один блок и добавляет контроль ошибок по-взрослому.
На практике чаще всего решает не «красота схемы», а предсказуемость исполнения. Костыли угрожают поддержке: новых сотрудников страшно подпускать к процессам, а диагностика превращается в квест с логами. Хороший признак — когда руководитель понимает, за что отвечает один понятный кирпич: «Синхронизируй доставку», а не «смотри тут 12 шагов, оно как-то работает».
Когда стандартных действий уже недостаточно
Есть три характерных триггера: нестандартная интеграция (подписи, токены, очереди), расчёты с ветвлениями (комиссии, прайсы, SLA) и тяжёлые проверки (дубли, скоринг, лимиты). В этих местах конвейер «робот на роботе» начинает трещать: слишком много мест, где всё может пойти не так, а отладка дороже внедрения.
Если система настроена правильно, вы ловите сигнал в моменте: схема разрастается, время исполнения прыгает, техподдержка жалуется на «нерепродуцируемые» баги. Это именно тот случай, когда создание активити в Битрикс24 упрощает и архитектуру, и поддержку — выносите сложность в изолированный, управляемый компонент.
Свой модуль против внешней доработки: что выгоднее
Два пути: писать модуль в коробочной версии или делать внешнее REST‑приложение со своим хендлером. Оба легальны, просто решают разные задачи и по-разному считаются в TCO. Ниже — без романтики, по делу. И да, речь именно про разработка активити Битрикс24, а не про «накликать роботов».
| Подход | Где живёт | Когда подходит | Плюсы | Ограничения | Стоимость владения |
|---|---|---|---|---|---|
| Модуль (коробка) | Внутри установки, код на PHP, регистрируется как активити/робот | Жёсткие требования по производительности и безопасности, офлайн‑контур | Максимальная скорость, доступ к внутренним API, единое логирование | Требует DevOps и версионирования, обновления коробки надо учитывать | Ниже подписка, выше поддержка: релизы, миграции, тесты |
| REST‑приложение + внешний сервис | Отдельный сервис/облако, активити регистрируется через REST | Облако, интеграции с внешними SaaS, быстрая разработка | Гибкость, независимые релизы, масштабирование снаружи | Сетевые задержки, лимиты REST, надо строить отказоустойчивость | Оплата инфраструктуры, но проще масштабировать и обновлять |
Как понять, какое активити реально окупится
Считать надо грубо и честно. Время, которое сотрудники тратят на обходные действия и разруливание сбоёв, умножьте на их ставку и частоту. Сравните с оценкой разработки + поддержки на год. Если получается точка безубыточности за 3–6 месяцев — зелёный свет.
Обычно всплывает одна и та же ошибка: оценивают фичу, а не владение. Любое кастомное активити Битрикс24 требует логирования, мониторинга и версий. Без этого экономия превращается в мираж — первый же апдейт CRM или внешний API ломают схему, и вы снова несёте ручками сделки через этапы.
Хороший признак — когда активити закрывает «сквозную» боль сразу в нескольких воронках и не зависит от прихотей интерфейса. Например, нормализация телефонов, валидация ИНН/НДС, внутренний скоринг, проверка лимитов дебиторки.
Пошагово: логика создания активити без хаоса
Здесь без романтики. Как сделать свое активити в Битрикс24 так, чтобы вы не пожалели через квартал.
- Соберите одну схему процесса без магии: входные данные, что делаем, какой ожидаем результат, что считаем ошибкой. Уберите лишние ветвления — активити не должно «думать» за бизнес.
- Опишите интерфейс активити: параметры на вход (поля CRM, константы), выходы (новые поля, комментарии, статус), таймауты и ретраи. Чем формальнее — тем легче тестировать.
- Выберите модель размещения: модуль в коробке или REST‑приложение. Проверьте требования безопасности и SLA внешних систем заранее.
- Сразу заложите логирование: вход/выход, корреляционный ID сделки, коды ошибок. Логи должны читаться людьми, а не только разработчиками.
- Решите вопрос с идемпотентностью: повторный запуск не должен портить данные. Храните маркеры выполненных шагов.
- Пропишите обработку отказов: чёткие статусы, уведомление ответственных, откат частичных изменений. «Упало тихо» — худший вариант.
- Сделайте версионирование: v1, v2, миграция параметров. Старые процессы не должны умереть в день релиза новой логики.
- Готовьте стенд: копия воронки, тестовые ключи внешних API, нагрузочные сценарии. Гоняйте крайние случаи, а не только «среднюю сделку».
- Катите постепенно: одна воронка, потом отдел, потом компания. Метрики до/после в явном виде.
Ошибки, из-за которых активити ломает процесс
Первое — блокирующие действия без таймаутов. Внешний сервис «задумался», процесс встал. Второе — жёсткая привязка к именам полей и стадиям, которые меняет маркетинг. Третье — нет уведомлений: отладка идёт через догадки, а не через события и логи.
- Отсутствие идемпотентности: повторное срабатывание плодит дубли и кашу в отчётах.
- Хардкод ID воронок/пользователей: любая реструктуризация ломает всё сразу.
- Игнорирование лимитов REST и очередей: «взрыв» при рассылках или импортах.
- Смешивание бизнес-логики и представления: активити делает и расчёт, и форматирует длинные комментарии — поддержка страдает.
- Нулевые тесты на ошибки: разработчик проверил «зелёный путь», а в реальности в 30% случаев прилетает неожиданный ответ.
Как подготовить Битрикс24 к масштабированию
Договоритесь о базовых правилах: каждое новое действие — с описанием параметров, версией, логами и правилами отката. Вынесите секреты и ключи в отдельный конфиг, доступ — по ролям. И заведите мониторинг: дашборд по ошибкам/времени ответа, чтобы не ловить пожар по жалобам.
Микро-сценарий. Вам нужно быстро подключать новые регионы с разными тарифами и партнёрскими правилами. Вместо копипаста роботов — один раз проектируете «Тарифный калькулятор» как активити, добавляете фичи-флаги и формулы в параметры. При следующем регионе меняете настройки, а не код. Вот это и есть тот момент, когда «делаем кастом — экономим нервы», а не наоборот.
Если вы узнали свои схемы — самое время навести порядок. Начните с короткого аудита ваших автоматизаций и концепта одного приоритетного действия, затем переходите к реализации. Нужна помощь с проектированием и разработкой — обратитесь в AMSALES: аккуратно упакуем логику в надёжный компонент и доведём до стабильного релиза. Посмотрите услугу «Программирование Битрикс24» — https://amsales.ru/services/dev/, договоримся о пилоте и сроках.
/ Поможем с этим