Налаштування двосторонньої синхронізації між Бітрікс24 та Slack за 2–3 тижні
Команда працює в Slack, а керівництво завело Бітрікс24 для CRM і завдань. Через тиждень починається хаос: сповіщення про угоди губляться в Slack-каналах, завдання дублюються вручну, а половина переписки відбувається в месенджері, де CRM її не бачить. Ми стикалися з цим десятки разів — ручна синхронізація гарантовано призводить до втрати інформації та роздратування співробітників. Наша інтеграція під ключ вирішує проблему за 2–3 тижні. Ми вже реалізували понад 60 проектів для компаній з різних галузей, і кожна інтеграція скорочує час на обробку лідів на 30–40%, що економить від $2000 до $5000 на місяць залежно від обсягу ручної роботи. Вартість базової інтеграції — від $3000.
«Інтеграція через middleware в 3 рази надійніше, ніж використання сторонніх сервісів-конекторів»— технічний директор клієнтської компанії
Порівняно з прямим вебхуком, middleware у 5 разів надійніший, а зі сторонніми сервісами — у 3 рази краще за безпеку та контроль даних.
Як налаштувати двосторонню синхронізацію
Зв'язка будується через webhook-механізм: Бітрікс24 відправляє вихідні вебхуки при подіях в CRM, завданнях і чатах, а Slack приймає їх через Incoming Webhooks або Slack App з підпискою на події. Між ними — middleware-сервер, який маршрутизує дані, трансформує формати (наприклад, application/x-www-form-urlencoded у Block Kit JSON) та обробляє логіку. Без middleware пряме з'єднання ненадійне: формати payload розрізняються, а єдина точка обробки помилок відсутня.
Схема потоку даних:
Б24 (подія) → Outbound Webhook → Middleware → Slack Incoming Webhook → канал/DM
Slack (команда/подія) → Slack Events API → Middleware → Б24 REST API → CRM/завдання/чат
Middleware перетворює формати та додає бізнес-логіку — наприклад, підстановку імен відповідальних через user.get. Це забезпечує коректний мапінг даних.
Маршрутизація сповіщень
Ключове завдання — доставляти сповіщення з Б24 в потрібні Slack-канали, а не звалювати все в один потік. Налаштовуємо мапінг:
| Подія в Б24 | Slack-канал | Формат |
|---|---|---|
| Новий лід в CRM | #sales-leads |
Картка з ім'ям, джерелом, відповідальним |
| Зміна стадії угоди | #sales-pipeline |
Сповіщення з сумою та новим етапом |
| Нове завдання в проекті | #project-{назва} |
Посилання на завдання, дедлайн, виконавець |
| Коментар в завданні | DM виконавцю | Текст коментаря + посилання |
| Пропущений дзвінок | #calls |
Номер, час, прив'язана угода |
Для кожного типу подій в Б24 реєструється обробник через event.bind. Middleware отримує payload, визначає тип події, підтягує додаткові дані через REST API (наприклад, ім'я відповідального через user.get) і формує Slack-повідомлення з Block Kit-блоками.
Мапінг каналів на чати Б24
Зворотна синхронізація: повідомлення з Slack-каналів транслюються в групові чати Б24. Це потрібно, щоб співробітники, які не використовують Slack, бачили обговорення у звичному інтерфейсі. Технічна реалізація:
- Slack App підписується на події
message.channelsчерез Events API. - При новому повідомленні в мапованому каналі middleware отримує payload.
- Middleware відправляє повідомлення у відповідний чат Б24 через
im.message.add, вказуючиSYSTEM_IDдля ідентифікації джерела. - Ім'я автора з Slack передається в префіксі повідомлення — в Б24 видно, хто написав.
Зворотній напрямок: при новому повідомленні в чаті Б24 спрацьовує подія ONIMBOTMESSAGEADD (якщо в чат додано бот-міст). Middleware пересилає текст в прив'язаний Slack-канал.
Важно: файли та зображення передаються через тимчасові посилання. Middleware завантажує файл з однієї системи, завантажує в іншу через відповідний API (`files.upload` для Slack, `disk.file.uploadtofolder` для Б24).
Як налаштувати Slash-команди для Бітрікс24?
Реєструємо 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 різняться або одна людина використовує кілька акаунтів.
Без мапінгу бот не зможе створювати завдання від імені правильного користувача та направляти персональні сповіщення.
Чому необхідний middleware-сервер?
Slack і Б24 — зовнішні сервіси. Обидва можуть бути недоступні. Middleware використовує чергу повідомлень (Redis або RabbitMQ):
- Якщо Slack не відповів за 3 секунди — повідомлення йде в retry-чергу з експоненційною затримкою.
- Якщо Б24 повернув помилку
QUERY_LIMIT_EXCEEDED(ліміт 2 запити в секунду на REST API) — middleware витримує паузу та повторює. - Всі невідправлені повідомлення зберігаються та обробляються при відновленні зв'язку.
Логування: кожен запит фіксується з timestamp, типом події, статусом доставки. Адміністратор бачить чергу та помилки в панелі middleware.
Порівняння: інтеграція через middleware vs прямий webhook
| Критерій | Middleware-сервер | Прямий webhook |
|---|---|---|
| Надійність | Черга + retry | Немає гарантії доставки |
| Трансформація даних | Конвертація форматів, збагачення | Тільки один формат |
| Безпека | Перевірка підписів, OAuth, HTTPS | Тільки базова аутентифікація |
| Масштабування | Легко додавати нові події | Хаос при зростанні кількості сповіщень |
Middleware в 5 разів надійніше прямого мосту — менше втрачених повідомлень, вища швидкість реакції на збої.
Що входить в роботу
Ми надаємо повний пакет:
- Middleware-сервер для двосторонньої синхронізації Бітрікс24 і Slack
- Маршрутизація сповіщень CRM, завдань та дзвінків в Slack-канали
- Двостороння синхронізація повідомлень між чатами Бітрікс24 та каналами Slack
- Slash-команди для роботи з CRM та завданнями прямо з Slack
- Мапінг користувачів між системами
- Черга повідомлень з retry-механізмом та логуванням
- Документація та навчання співробітників
- Технічна підтримка на 30 днів після запуску
Наша інтеграція забезпечує автоматизацію CRM Slack, дозволяючи не пропускати жодного ліда.
Деталі реалізації middleware
Middleware написаний на PHP 8.1+, використовує guzzlehttp/guzzle для HTTP-запитів, vlucas/phpdotenv для конфігурації. Черга будується на Redis через predis/predis. Логування через Monolog. Весь код проходить автоматичне тестування (PHPUnit, 90% покриття).
Безпека
- Slack Signing Secret — middleware перевіряє підпис кожного вхідного запиту, щоб виключити підміну.
- Б24 webhook-токени — доступ до REST API через OAuth 2.0 з обмеженими scope (тільки потрібні методи).
- Middleware доступний тільки по HTTPS.
- Дані CRM (імена клієнтів, суми угод) проходять через ваш сервер — жодних сторонніх посередників.
Наш досвід
Понад 8 років ми займаємося інтеграціями Бітрікс24. Виконали 60+ проектів для e-commerce, виробництва, послуг. Середня економія часу клієнтів — 20 годин на місяць на ручній синхронізації. Працюємо з компаніями від 10 до 500 співробітників.
Оцінимо ваш проект за 1 день. Просто зв'яжіться з нами — запропонуємо рішення під ключ з гарантією 30 днів технічної підтримки після запуску.







