Интеграция Битрикс24 с Slack

Интеграция Битрикс24 с Slack

Команда работает в Slack, а руководство завело Битрикс24 для CRM и задач. Через неделю начинается хаос: уведомления о сделках теряются в Slack-каналах, задачи дублируются вручную, а половина переписки происходит в мессенджере, где CRM её не видит. Синхронизировать два инструмента руками — гарантированный путь к потере информации и раздражению сотрудников.

Архитектура интеграции

Связка строится через webhook-механизм: Битрикс24 отправляет исходящие вебхуки при событиях в CRM, задачах и чатах, а Slack принимает их через Incoming Webhooks или Slack App с подпиской на события. Между ними — middleware-сервер, который маршрутизирует данные, трансформирует форматы и обрабатывает логику.

Схема потока данных:

Б24 (событие) → Outbound Webhook → Middleware → Slack Incoming Webhook → канал/DM
Slack (команда/событие) → Slack Events API → Middleware → Б24 REST API → CRM/задачи/чат

Middleware необходим, потому что Б24 и Slack используют разные форматы payload. Б24 отправляет данные в формате application/x-www-form-urlencoded, Slack ожидает JSON с Block Kit-разметкой. Middleware преобразует одно в другое и добавляет бизнес-логику.

Маршрутизация уведомлений

Ключевая задача — доставлять уведомления из Б24 в нужные Slack-каналы, а не сваливать всё в один поток.

Настраиваем маппинг:

Для каждого типа событий в Б24 регистрируется обработчик через event.bind. Middleware получает payload, определяет тип события, подтягивает дополнительные данные через REST API (например, имя ответственного через user.get) и формирует Slack-сообщение с Block Kit-блоками.

Маппинг каналов на чаты Б24

Обратная синхронизация: сообщения из Slack-каналов транслируются в групповые чаты Б24. Это нужно, чтобы сотрудники, которые не используют Slack, видели обсуждения в привычном интерфейсе.

Техническая реализация:

1. Slack App подписывается на события message.channels через Events API.
2. При новом сообщении в маппированном канале middleware получает payload.
3. Middleware отправляет сообщение в соответствующий чат Б24 через im.message.add, указывая SYSTEM_ID для идентификации источника.
4. Имя автора из Slack передаётся в префиксе сообщения — в Б24 видно, кто написал.

Обратное направление: при новом сообщении в чате Б24 срабатывает событие ONIMBOTMESSAGEADD (если в чат добавлен бот-мост). Middleware пересылает текст в привязанный Slack-канал.

Важно: файлы и изображения передаются через временные ссылки. Middleware скачивает файл из одной системы, загружает в другую через соответствующий API (files.upload для Slack, disk.file.uploadtofolder для Б24).

Slash-команды и бот в Slack

Регистрируем Slack-команды, которые обращаются к Б24:

• /b24-lead Компания | Комментарий — создаёт лид в CRM через crm.lead.add. Возвращает ссылку на созданный лид.
• /b24-task Название | Описание | @исполнитель — создаёт задачу через tasks.task.add. Ищет пользователя в Б24 по email, привязанному к Slack-аккаунту.
• /b24-deal ID — показывает информацию о сделке: стадия, сумма, ответственный, следующая активность.
• /b24-status — выводит сводку: количество лидов за сегодня, открытые задачи пользователя, пропущенные звонки.

Каждая команда отправляет POST-запрос на middleware. Middleware аутентифицирует пользователя (маппинг Slack User ID → Б24 User ID через таблицу соответствий), выполняет запрос к REST API Б24 и возвращает ответ в Slack как ephemeral message (видит только автор команды) или in-channel message.

Маппинг пользователей

Для корректной работы нужна таблица соответствий пользователей. Два подхода:

• По email. Middleware сопоставляет email из Slack-профиля с email пользователя в Б24 (через user.get с фильтром). Работает автоматически, если email совпадают.
• Ручная привязка. Администратор задаёт пары через интерфейс middleware. Нужно, когда email различаются или один человек использует несколько аккаунтов.

Без маппинга бот не сможет создавать задачи от имени правильного пользователя и направлять персональные уведомления.

Обработка ошибок и очереди

Slack и Б24 — внешние сервисы. Оба могут быть недоступны. Middleware использует очередь сообщений (Redis или RabbitMQ):

• Если Slack не ответил за 3 секунды — сообщение уходит в retry-очередь с экспоненциальной задержкой.
• Если Б24 вернул ошибку QUERY_LIMIT_EXCEEDED (лимит 2 запроса в секунду на REST API) — middleware выдерживает паузу и повторяет.
• Все неотправленные сообщения сохраняются и обрабатываются при восстановлении связи.

Логирование: каждый запрос фиксируется с timestamp, типом события, статусом доставки. Администратор видит очередь и ошибки в панели middleware.

Безопасность

• Slack Signing Secret — middleware проверяет подпись каждого входящего запроса, чтобы исключить подмену.
• Б24 webhook-токены — доступ к REST API через OAuth 2.0 с ограниченными scope (только нужные методы).
• Middleware доступен только по HTTPS. Данные CRM (имена клиентов, суммы сделок) проходят через ваш сервер — никаких сторонних посредников.

Что внедряем

• Middleware-сервер для двусторонней синхронизации Б24 и Slack
• Маршрутизация уведомлений CRM, задач и звонков в Slack-каналы
• Двусторонняя синхронизация сообщений между чатами Б24 и каналами Slack
• Slash-команды для работы с CRM и задачами прямо из Slack
• Маппинг пользователей между системами
• Очередь сообщений с retry-механизмом и логированием