Межпортальные чаты 2.0: единое пространство переписки для компаний с несколькими порталами Битрикс24

Введение

Когда у компании два и более портала Битрикс24, переписка между ними превращается в ручную работу. Сотрудники копируют сообщения, пересылают файлы через сторонние мессенджеры, дублируют задачи в разных системах. На практике это означает, что до 30% рабочего времени поддержки и проектных команд уходит не на работу, а на перекладывание информации между порталами.

Приложение «Межпортальные чаты 2.0» решает эту проблему на уровне инфраструктуры: оно связывает чаты разных порталов так, что сообщения, файлы и задачи передаются автоматически. Пользователи продолжают работать в привычном интерфейсе Битрикс24 — в чатах, открытых линиях и коллабах, — а приложение обеспечивает маршрутизацию, доставку и защиту от дублирования.

В этой статье разберём, как устроена связка порталов, какие сценарии покрывает приложение, как работает синхронизация задач и какие ошибки допускают при внедрении.

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

Приложение устанавливается как стандартное приложение Маркетплейса и регистрирует собственный коннектор открытых линий с идентификатором swebs_chat_v_chat2. После установки в интерфейсе появляется два раздела: «Клиентский» и «Партнёрский» — каждый со своим набором настроек.

В клиентском разделе настраиваются боты, которые будут принимать сообщения от пользователей и передавать их на портал партнёра. В партнёрском — открытые линии, боты-партнёры и связки с клиентскими порталами.

Интеграция затрагивает следующие сущности Битрикс24:

• Открытые линии (imconnector) — приложение регистрирует коннектор, через который сообщения клиента попадают в очередь оператора на портале партнёра.
• Чат-боты (imbot) — боты v2 создаются и настраиваются через API, используются для маршрутизации сообщений между порталами.
• Чаты и групповые чаты (im.chat) — стандартные чаты Битрикс24, в которые добавляются боты для пересылки сообщений.
• Коллабы (collab) — поддержка коллаб как получателя сообщений добавлена в последних версиях; бот добавляется вручную пользователем.
• Задачи (tasks.task) — в контуре Task Sync создаются и синхронизируются задачи между порталами.

Приложение работает как в десктопной версии Битрикс24, так и в мобильном приложении. Для мобильных устройств реализовано адаптивное поведение: вместо нестабильных слайдеров используется прямой переход на страницы, что даёт предсказуемый UX.

Автоматизация межпортальной переписки

Что заменяет приложение

До внедрения общение между порталами выглядит так: сотрудник на портале А пишет сообщение, делает скриншот или копирует текст, открывает сторонний мессенджер, пересылает коллеге на портале Б. Тот вручную создаёт задачу, прикрепляет файл, отвечает — и цикл повторяется в обратную сторону. При нескольких активных проектах между одними и теми же порталами эта механика множится и порождает ошибки: сообщение ушло не туда, файл потерялся, задачу забыли продублировать.

После настройки приложения:

• сообщение, отправленное в чат с ботом на портале А, автоматически появляется в открытой линии или целевом чате на портале Б;
• ответ с портала Б возвращается в исходный чат портала А;
• файлы передаются вместе с сообщениями, с опциональным перехостингом на принимающий портал;
• дубликаты сообщений отсекаются на уровне вебхуков (защита от парных событий ONIMBOTMESSAGEADD / ONIMBOTV2MESSAGEADD);
• петли эха при пересылке файлов между ботами блокируются до попадания в чат.

Режимы маршрутизации

Приложение поддерживает три сценария маршрутизации:

1. Клиент → Открытая линия партнёра. Классическая сервисная модель: клиент пишет в чат с ботом на своём портале, сообщение приходит в открытую линию на портале партнёра. Оператор отвечает — ответ возвращается клиенту. Подходит для техподдержки, аутсорсинговых колл-центров и сервисных компаний.

2. Чат ↔ Чат (бот ↔ бот). Двусторонняя синхронизация между групповыми чатами. На обеих сторонах создаются боты, связываются между собой, и сообщения из одного чата автоматически попадают в другой. Подходит для проектных команд, работающих в разных порталах над общими задачами.

3. Коллаба как получатель. Новый сценарий: сообщения маршрутизируются в коллабу на принимающей стороне. Бот добавляется в коллабу вручную — это ограничение API Битрикс24, а не приложения. После добавления бот полноценно участвует в переписке коллабы.

Защитные механизмы доставки

Надёжность доставки обеспечивается эшелонированной логикой:

• Дедупликация вебхуков: парные события ONIMBOTMESSAGEADD (старый формат) и ONIMBOTV2MESSAGEADD (новый формат) приходят одновременно — приложение пропускает только одно.
• Anti-echo защита: если бот переслал файл и получил эхо собственного сообщения, оно не создаёт повторной пересылки.
• Валидация payload: перед отправкой проверяется BOT_ID, DIALOG_ID, согласованность с типом получателя (чат/коллаба).
• Fallback-отправка: сначала используется imbot.v2.Chat.Message.send, при отказе — imbot.message.add.

Пересылка файлов

Файлы передаются в одном из двух режимов:

• Без перехостинга: в сообщение вставляется ссылка на файл с портала-источника. Быстро, но требует доступа к исходному порталу.
• С перехостингом: файл скачивается с портала-отправителя, загружается в хранилище портала-получателя и отправляется уже оттуда. Надёжно, но занимает время и требует дискового пространства.

Режим настраивается отдельно для каждой стороны связки флагами rehost_files_on_partner и rehost_files_on_client. Если перехостинг не удался, получатель видит уведомление о сбое вложения, а отправитель получает служебное сообщение об ошибке.

Создание задач из чата

Отдельный сценарий, не зависящий от синхронизации задач: при открытии placement «создать задачу из чата» пользователь заполняет форму (название, описание, срок) и задача создаётся на портале партнёра. Параметры назначения (группа и ответственный) берутся из настроек связки ботов.

Межпортальные задачи (Task Sync, BETA)

Контур синхронизации задач проектно отделён от механики чатов. Это самостоятельный модуль со своей логикой связывания и передачи данных.

Как работает

1. Связка порталов. Партнёр генерирует ключ-приглашение (hash с TTL). Клиент вводит ключ в своём интерфейсе. В базе фиксируется связка порталов. Повторная активация обрабатывается идемпотентно.

2. Сопоставление групп. Партнёр задаёт пары «группа партнёра → группа клиента». Для каждой пары включаются флаги: синхронизировать задачи и синхронизировать чат задачи.

3. Периодический синк. Встроенный планировщик с настраиваемым интервалом (по умолчанию 120 секунд) инкрементально опрашивает изменения задач. Для каждой задачи ведётся зеркало: partner_task_id ↔ client_task_id. При конфликтах используется политика last-write-wins. Для предотвращения эха после обновления выставляются временные ignore-lock-окна.

При потере зеркала задача помечается суффиксом tsync-off — это сигнал администратору, что синхронизация по данной задаче нарушена.

Масштабирование

При высоких нагрузках синхронизация задач может идти через Kafka: отдельные очереди для синхронизации полей (task-sync-fields) и файлов (task-sync-files), с dead-letter-очередями для проблемных сообщений. Consumer'ы полей поддерживают параллельную обработку (до 3 воркеров настраиваемой конкурентностью).

Текущий статус

Модуль Task Sync находится в статусе BETA. В production на июнь 2026 года работает связка порталов iridi.bitrix24.ru ↔ uhome.bitrix24.ru с сопоставлением групп в обоих направлениях.

Кейсы внедрения

Кейс 1: Сервисная компания — техподдержка клиентов

Ситуация. IT-интегратор обслуживает 20+ клиентов, у каждого свой портал Битрикс24. Заявки приходят в чаты на клиентских порталах, инженеры работают на портале интегратора.

До внедрения. Переписка шла черезemail и Telegram. Инженеры не видели контекст заявки внутри CRM клиента. Среднее время ответа — 4 часа. 15% заявок терялись при передаче между каналами.

После внедрения. Чат с ботом на каждом клиентском портале подключён к открытой линии интегратора. Инженер видит сообщение клиента в своей очереди, отвечает — ответ возвращается в клиентский чат. Время первого ответа сократилось до 20 минут. Потери заявок — 0.

Кейс 2: Строительный холдинг — два портала, одна команда

Ситуация. Управляющая компания и стройплощадка работают в разных порталах. Прорабы на объекте пользуются одним порталом, проектный офис — другим. Задачи и чертежи нужно передавать между порталами по несколько раз в день.

До внедрения. Файлы пересылались через WhatsApp. Задачи дублировались вручную. Сроки согласования документации — до 3 дней.

После внедрения. Настроена связка чат↔чат между групповыми чатами порталов, включён перехостинг файлов. Чертежи и спецификации передаются с сохранением в хранилище принимающего портала. Срок согласования сократился до одного рабочего дня. Дублирование задач ушло благодаря Task Sync.

Кейс 3: Франчайзинговая сеть — головной офис и филиалы

Ситуация. Франчайзер на своём портале, 10 франчайзи — каждый на своём. Нужен сквозной канал связи «франчайзи → поддержка головного офиса».

До внедрения. Франчайзи звонили или писали в WhatsApp. Контекст обращений не фиксировался в CRM. Головной офис не имел статистики по типам обращений и времени решения.

После внедрения. На каждом портале франчайзи настроен чат с ботом, подключённый к открытой линии головного офиса. Все обращения фиксируются в CRM, доступна история переписки, время ответа и решение. Руководитель поддержки видит отчёт по всем филиалам в едином интерфейсе.

Кейс 4: Проектный офис — синхронизация задач между порталами (Task Sync)

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

До внедрения. Задачи переносились через экспорт/импорт CSV раз в неделю. При изменении задачи на одной стороне вторая оставалась неактуальной. 30% задач имели расхождения по статусу и срокам.

После внедрения. Настроена связка порталов через Task Sync с сопоставлением проектных групп. Задачи синхронизируются инкрементально каждые 2 минуты. Расхождений по статусу — 0 (в пределах окна синхронизации). Экспорт задач отключён за ненадобностью.

Типичные ошибки при внедрении

1. Ожидание, что user→user работает

Режим пересылки сообщений между конкретными пользователями (user → user) временно отключён — и в интерфейсе, и на уровне валидации backend. При попытке выбрать получателем пользователя приложение не даст сохранить настройки. Правильный путь: использовать групповой чат или коллабу.

2. Бот не добавлен в коллабу вручную

Для коллаб API Битрикс24 не позволяет гарантированно добавить бота автоматически, как в обычный чат. Если не добавить бота вручную через интерфейс коллабы, сообщения маршрутизируются, но бот не сможет их доставить. Симптом: в логах трассировки видно, что маршрут отработал, а сообщение не появилось.

3. Не включены нужные права для REST-методов

Приложение требует доступ к imbot, imconnector, im, tasks и task. Если при установке не выданы все запрошенные права, часть функций не заработает. Проверка: после установки открыть карточку приложения в админке Битрикс24 и убедиться, что все скоупы активны.

4. Не настроена очередь открытой линии

После создания связки «клиент → открытая линия» сообщения падают в открытую линию, но если к ней не привязана очередь операторов — отвечать будет некому. Настройка очереди — зона ответственности администратора портала партнёра, приложение её не конфигурирует.

5. Task Sync запущен без проверки сетевой доступности

Синхронизация задач между порталами требует, чтобы backend-сервер приложения имел сетевой доступ к REST API обоих порталов. В коробочных версиях Битрикс24 это не всегда так: портал может быть за файрволом. Решение: белый список IP сервера приложения на обоих порталах или разворот приложения в одном сетевом контуре.

Сравнение с альтернативами

Штатный функционал Битрикс24

Штатно Битрикс24 не предоставляет межпортальной пересылки сообщений. Можно создать общего пользователя на нескольких порталах и переключаться между ними, но это не решает задачу автоматической маршрутизации. Открытые линии работают только с внешними каналами (Telegram, WhatsApp, ВКонтакте), но не с другими порталами Битрикс24.

Ручная пересылка (email, мессенджеры)

Самый распространённый «конкурент» приложения. Плюс: не требует настройки. Минусы: время, ошибки, отсутствие audit trail, невозможность синхронизации задач. При двух порталах и 20+ активных переписках в день ручной режим даёт потери на уровне 2–4 часов в день на сотрудника.

Другие приложения Маркетплейса

На момент написания статьи в Маркетплейсе нет приложения, которое одновременно решает задачи межпортальной переписки и синхронизации задач. Существуют решения для трансляции сообщений в Telegram из чатов Битрикс24, но они не покрывают сценарий «портал ↔ портал».

Самописное решение

Написать своего бота для пересылки сообщений через REST API imbot технически возможно. Однако потребуется решить те же проблемы, которые уже решены в «Межпортальных чатах 2.0»: дедупликация вебхуков, защита от эха, fallback-доставка, трассировка, синхронизация задач с conflict resolution, мобильная адаптация, управление ключами приглашений. Оценка трудозатрат — от 200 часов разработки и 50 часов поддержки в год. Приложение же устанавливается и настраивается за 1–2 часа.

FAQ

Можно ли связать больше двух порталов? Да. Каждая связка настраивается попарно: портал А ↔ портал Б, портал А ↔ портал В и так далее. Ограничений по количеству связок нет.

Работает ли приложение на коробочном Битрикс24? Да, при выполнении требований к версиям модулей: «Мгновенные сообщения» не ниже 26.250.0 и «Чат-боты Битрикс24» не ниже 26.50.0.

Нужен ли отдельный сервер? Да, приложение требует собственный backend (FastAPI + PostgreSQL). Поставляется в Docker-контейнерах, разворачивается через Docker Compose. Может работать за nginx-прокси или на выделенном хосте.

Что с защитой данных? Сообщения передаются по HTTPS между порталами через backend приложения. Backend не хранит содержимое сообщений — только метаданные для трассировки. Файлы при перехостинге временно сохраняются и удаляются после передачи. Доступ к API порталов — через OAuth-токены, полученные при установке приложения.

Можно ли синхронизировать задачи без чатов? Да, контур Task Sync не зависит от чатов. Можно настроить только связку порталов и сопоставление групп для синхронизации задач, не настраивая ботов и чаты.

Как понять, что сообщение не дошло? В приложении ведётся трассировочный лог потока сообщений: входящий вебхук → шаги маршрутизации → исходящие REST-вызовы → подтверждение доставки. По логам можно отследить путь любого сообщения и найти точку отказа.

Сколько времени занимает настройка? Базовая связка «клиент → открытая линия» настраивается за 15–20 минут. Полный цикл с чат↔чат, файлами и Task Sync — 1–2 часа с учётом проверки всех сценариев.

SEO-блок

Высокочастотные: межпортальные чаты, чат между порталами битрикс24, синхронизация чатов битрикс24, интеграция порталов битрикс24.

Среднечастотные: межпортальная переписка битрикс24, связать чаты битрикс24, синхронизация задач между порталами, пересылка сообщений битрикс24, бот для связи порталов, открытая линия между порталами, task sync битрикс24.

Длинный хвост: как связать два портала битрикс24 чатами, синхронизация задач между разными порталами битрикс24, переписка между филиалами битрикс24, межпортальные чаты 2.0, перехостинг файлов между порталами, коллабы межпортальная связь.

Заключение

«Межпортальные чаты 2.0» решают конкретную инфраструктурную задачу: автоматическую передачу сообщений, файлов и задач между порталами Битрикс24 без дублирования, потерь и ручной работы. Приложение подходит компаниям, у которых два и более активных портала и есть устойчивый поток коммуникаций между ними.

С чего начать: установите приложение в обоих порталах, создайте пробную связку «клиент → открытая линия» и проверьте прохождение сообщений в обе стороны. Затем расширяйте конфигурацию: добавьте чат↔чат-связки, настройте перехостинг файлов, при необходимости подключите Task Sync для синхронизации задач.

Результат оценивается по объективным метрикам: время прохождения сообщения между порталами (должно быть в пределах 2–5 секунд), отсутствие потерянных сообщений (проверяется по трассировочному логу), сокращение ручных операций по переносу информации (должно стремиться к нулю для настроенных связок).