Інтеграція Bitrix24 та Slack
Ваша команда працює в Slack, але керівництво завело Bitrix24 для CRM та задач. За тиждень починається хаос: сповіщення про угоди теряються в Slack-каналах, задачі дублюються вручну, а половина переписки відбувається в месенджері, де CRM це не бачить. Синхронізація двох інструментів вручну гарантує втрату інформації та розчарування співробітників.
Архітектура інтеграції
Зв'язок будується за допомогою webhook-механізму: Bitrix24 відправляє вихідні вебхуки при подіях у CRM, задачах та чатах, а Slack отримує їх через Incoming Webhooks або Slack App з підписами на події. Між ними стоїть middleware-сервер, який маршрутизує дані, трансформує формати та обробляє логіку.
Схема потоку даних:
B24 (подія) → Outbound Webhook → Middleware → Slack Incoming Webhook → канал/DM
Slack (команда/подія) → Slack Events API → Middleware → B24 REST API → CRM/задачі/чат
Middleware необхідний, оскільки B24 та Slack використовують різні формати payload. B24 відправляє дані як application/x-www-form-urlencoded, Slack очікує JSON з Block Kit-розміткою. Middleware перетворює одне в інше та додає бізнес-логіку.
Маршрутизація сповіщень
Ключова завдання — доставляти сповіщення з B24 у потрібні Slack-канали, а не складати все в один потік.
Налаштовуємо маппінг:
| Подія в B24 | Slack-канал | Формат |
|---|---|---|
| Новий лід в CRM | #sales-leads |
Карточка з ім'ям, джерелом, відповідальним |
| Зміна стадії угоди | #sales-pipeline |
Сповіщення з сумою та новим етапом |
| Нова задача в проекті | #project-{назва} |
Посилання на задачу, дедлайн, виконавець |
| Коментар у задачі | DM виконавцю | Текст коментаря + посилання |
| Пропущений дзвінок | #calls |
Номер, час, пов'язана угода |
Для кожного типу подій в B24 реєструється обробник через event.bind. Middleware отримує payload, визначає тип подіï, підтягує додаткові дані через REST API (наприклад, ім'я відповідальної особи через user.get) та формує Slack-сповіщення з Block Kit-блоками.
Маппінг каналів на чати B24
Зворотня синхронізація: повідомлення з Slack-каналів транслюються в групові чати B24. Це потрібно, щоб співробітники, які не користуються Slack, бачили обговорення у звичному інтерфейсі.
Технічна реалізація:
- Slack App підписується на події
message.channelsчерез Events API. - При новому повідомленні в маппованому каналі middleware отримує payload.
- Middleware відправляє повідомлення у відповідний чат B24 через
im.message.add, вказуючиSYSTEM_IDдля ідентифікації джерела. - Ім'я автора з Slack передається в префіксі повідомлення — у B24 видно, хто написав.
Зворотне направлення: при новому повідомленні в чаті B24 спрацьовує подія ONIMBOTMESSAGEADD (якщо в чат додано бот-міст). Middleware перенаправляє текст у пов'язаний Slack-канал.
Важливо: файли та зображення передаються через тимчасові посилання. Middleware скачує файл з однієї системи, завантажує в іншу через відповідний API (files.upload для Slack, disk.file.uploadtofolder для B24).
Slash-команди та бот у Slack
Реєструємо Slack-команди, які звертаються до B24:
-
/b24-lead Компанія | Коментар— створює лід у CRM черезcrm.lead.add. Повертає посилання на створений лід. -
/b24-task Назва | Опис | @виконавець— створює задачу черезtasks.task.add. Шукає користувача в B24 за email, пов'язаним зі Slack-аккаунтом. -
/b24-deal ID— показує інформацію про угоду: стадія, сума, відповідальний, наступна активність. -
/b24-status— виводить зведку: кількість лідів за сьогодні, відкриті задачі користувача, пропущені дзвінки.
Кожна команда відправляє POST-запит на middleware. Middleware аутентифікує користувача (маппінг Slack User ID → B24 User ID через таблицю відповідностей), виконує запит до REST API B24 та повертає відповідь у Slack як ephemeral message (видить тільки автор команди) або in-channel message.
Маппінг користувачів
Для коректної роботи потрібна таблиця відповідностей користувачів. Два підходи:
-
За email. Middleware зіставляє email з Slack-профіля з email користувача в B24 (через
user.getз фільтром). Працює автоматично, якщо email збігаються. - Ручна привязка. Адміністратор задає пари через інтерфейс middleware. Потрібна, коли email різні або одна людина користується кількома аккаунтами.
Без маппінгу бот не зможе створювати задачі від імені правильного користувача та спрямовувати персональні сповіщення.
Обробка помилок та черги
Slack та B24 — зовнішні сервіси. Обидва можуть бути недоступні. Middleware використовує чергу повідомлень (Redis або RabbitMQ):
- Якщо Slack не відповів за 3 секунди — повідомлення йде в retry-чергу з експоненціальною затримкою.
- Якщо B24 повернув помилку
QUERY_LIMIT_EXCEEDED(лімріт 2 запити на секунду для REST API) — middleware витримує паузу та повторює. - Всі невідправлені повідомлення зберігаються та обробляються при відновленні зв'язку.
Логування: кожен запит фіксується з timestamp, типом подіï, статусом доставки. Адміністратор бачить чергу та помилки на панелі middleware.
Безпека
- Slack Signing Secret — middleware перевіряє підпис кожного вхідного запиту, щоб виключити підстановку.
- B24 webhook-токени — доступ до REST API через OAuth 2.0 з обмеженими scope (тільки потрібні методи).
- Middleware доступний тільки по HTTPS. Дані CRM (імена клієнтів, суми угод) проходять через ваш сервер — жодних сторонніх посередників.
Що впроваджуємо
- Middleware-сервер для двосторонньої синхронізації B24 та Slack
- Маршрутизація сповіщень CRM, задач та дзвінків у Slack-канали
- Двостороння синхронізація повідомлень між чатами B24 та каналами Slack
- Slash-команди для роботи з CRM та задачами прямо з Slack
- Маппінг користувачів між системами
- Чергу повідомлень з retry-механізмом та логуванням