[{"data":1,"prerenderedAt":13},["ShallowReactive",2],{"$fX9wM3eRzZRijbFhH5Ga1G6a5MKsbrDW3m2PAnZZbb30":3},{"slug":4,"title":5,"published":6,"publishedAt":7,"section":8,"preview":9,"previewImage":10,"bodyMd":11,"bodyHtml":12},"mezhportalnye-chaty-2-0","Межпортальные чаты 2.0: единое пространство переписки для компаний с несколькими порталами Битрикс24",true,"07.06.2026 16:40:45","Приложения","Как связать чаты, открытые линии и задачи между разными порталами Битрикс24. Автоматическая пересылка сообщений и файлов, синхронизация задач, защита от дубл...",null,"# Межпортальные чаты 2.0: единое пространство переписки для компаний с несколькими порталами Битрикс24\n\n## Введение\n\nКогда у компании два и более портала Битрикс24, переписка между ними превращается в ручную работу. Сотрудники копируют сообщения, пересылают файлы через сторонние мессенджеры, дублируют задачи в разных системах. На практике это означает, что до 30% рабочего времени поддержки и проектных команд уходит не на работу, а на перекладывание информации между порталами.\n\nПриложение «Межпортальные чаты 2.0» решает эту проблему на уровне инфраструктуры: оно связывает чаты разных порталов так, что сообщения, файлы и задачи передаются автоматически. Пользователи продолжают работать в привычном интерфейсе Битрикс24 — в чатах, открытых линиях и коллабах, — а приложение обеспечивает маршрутизацию, доставку и защиту от дублирования.\n\nВ этой статье разберём, как устроена связка порталов, какие сценарии покрывает приложение, как работает синхронизация задач и какие ошибки допускают при внедрении.\n\n## Интеграция с CRM Битрикс24\n\nПриложение устанавливается как стандартное приложение Маркетплейса и регистрирует собственный коннектор открытых линий с идентификатором `swebs_chat_v_chat2`. После установки в интерфейсе появляется два раздела: «Клиентский» и «Партнёрский» — каждый со своим набором настроек.\n\nВ клиентском разделе настраиваются боты, которые будут принимать сообщения от пользователей и передавать их на портал партнёра. В партнёрском — открытые линии, боты-партнёры и связки с клиентскими порталами.\n\nИнтеграция затрагивает следующие сущности Битрикс24:\n\n- **Открытые линии (imconnector)** — приложение регистрирует коннектор, через который сообщения клиента попадают в очередь оператора на портале партнёра.\n- **Чат-боты (imbot)** — боты v2 создаются и настраиваются через API, используются для маршрутизации сообщений между порталами.\n- **Чаты и групповые чаты (im.chat)** — стандартные чаты Битрикс24, в которые добавляются боты для пересылки сообщений.\n- **Коллабы (collab)** — поддержка коллаб как получателя сообщений добавлена в последних версиях; бот добавляется вручную пользователем.\n- **Задачи (tasks.task)** — в контуре Task Sync создаются и синхронизируются задачи между порталами.\n\nПриложение работает как в десктопной версии Битрикс24, так и в мобильном приложении. Для мобильных устройств реализовано адаптивное поведение: вместо нестабильных слайдеров используется прямой переход на страницы, что даёт предсказуемый UX.\n\n## Автоматизация межпортальной переписки\n\n### Что заменяет приложение\n\nДо внедрения общение между порталами выглядит так: сотрудник на портале А пишет сообщение, делает скриншот или копирует текст, открывает сторонний мессенджер, пересылает коллеге на портале Б. Тот вручную создаёт задачу, прикрепляет файл, отвечает — и цикл повторяется в обратную сторону. При нескольких активных проектах между одними и теми же порталами эта механика множится и порождает ошибки: сообщение ушло не туда, файл потерялся, задачу забыли продублировать.\n\nПосле настройки приложения:\n\n- сообщение, отправленное в чат с ботом на портале А, автоматически появляется в открытой линии или целевом чате на портале Б;\n- ответ с портала Б возвращается в исходный чат портала А;\n- файлы передаются вместе с сообщениями, с опциональным перехостингом на принимающий портал;\n- дубликаты сообщений отсекаются на уровне вебхуков (защита от парных событий `ONIMBOTMESSAGEADD` \u002F `ONIMBOTV2MESSAGEADD`);\n- петли эха при пересылке файлов между ботами блокируются до попадания в чат.\n\n### Режимы маршрутизации\n\nПриложение поддерживает три сценария маршрутизации:\n\n1. **Клиент → Открытая линия партнёра.** Классическая сервисная модель: клиент пишет в чат с ботом на своём портале, сообщение приходит в открытую линию на портале партнёра. Оператор отвечает — ответ возвращается клиенту. Подходит для техподдержки, аутсорсинговых колл-центров и сервисных компаний.\n\n2. **Чат ↔ Чат (бот ↔ бот).** Двусторонняя синхронизация между групповыми чатами. На обеих сторонах создаются боты, связываются между собой, и сообщения из одного чата автоматически попадают в другой. Подходит для проектных команд, работающих в разных порталах над общими задачами.\n\n3. **Коллаба как получатель.** Новый сценарий: сообщения маршрутизируются в коллабу на принимающей стороне. Бот добавляется в коллабу вручную — это ограничение API Битрикс24, а не приложения. После добавления бот полноценно участвует в переписке коллабы.\n\n### Защитные механизмы доставки\n\nНадёжность доставки обеспечивается эшелонированной логикой:\n\n- **Дедупликация вебхуков**: парные события `ONIMBOTMESSAGEADD` (старый формат) и `ONIMBOTV2MESSAGEADD` (новый формат) приходят одновременно — приложение пропускает только одно.\n- **Anti-echo защита**: если бот переслал файл и получил эхо собственного сообщения, оно не создаёт повторной пересылки.\n- **Валидация payload**: перед отправкой проверяется `BOT_ID`, `DIALOG_ID`, согласованность с типом получателя (чат\u002Fколлаба).\n- **Fallback-отправка**: сначала используется `imbot.v2.Chat.Message.send`, при отказе — `imbot.message.add`.\n\n### Пересылка файлов\n\nФайлы передаются в одном из двух режимов:\n\n- **Без перехостинга**: в сообщение вставляется ссылка на файл с портала-источника. Быстро, но требует доступа к исходному порталу.\n- **С перехостингом**: файл скачивается с портала-отправителя, загружается в хранилище портала-получателя и отправляется уже оттуда. Надёжно, но занимает время и требует дискового пространства.\n\nРежим настраивается отдельно для каждой стороны связки флагами `rehost_files_on_partner` и `rehost_files_on_client`. Если перехостинг не удался, получатель видит уведомление о сбое вложения, а отправитель получает служебное сообщение об ошибке.\n\n### Создание задач из чата\n\nОтдельный сценарий, не зависящий от синхронизации задач: при открытии placement «создать задачу из чата» пользователь заполняет форму (название, описание, срок) и задача создаётся на портале партнёра. Параметры назначения (группа и ответственный) берутся из настроек связки ботов.\n\n## Межпортальные задачи (Task Sync, BETA)\n\nКонтур синхронизации задач проектно отделён от механики чатов. Это самостоятельный модуль со своей логикой связывания и передачи данных.\n\n### Как работает\n\n1. **Связка порталов.** Партнёр генерирует ключ-приглашение (hash с TTL). Клиент вводит ключ в своём интерфейсе. В базе фиксируется связка порталов. Повторная активация обрабатывается идемпотентно.\n\n2. **Сопоставление групп.** Партнёр задаёт пары «группа партнёра → группа клиента». Для каждой пары включаются флаги: синхронизировать задачи и синхронизировать чат задачи.\n\n3. **Периодический синк.** Встроенный планировщик с настраиваемым интервалом (по умолчанию 120 секунд) инкрементально опрашивает изменения задач. Для каждой задачи ведётся зеркало: `partner_task_id ↔ client_task_id`. При конфликтах используется политика last-write-wins. Для предотвращения эха после обновления выставляются временные ignore-lock-окна.\n\nПри потере зеркала задача помечается суффиксом `tsync-off` — это сигнал администратору, что синхронизация по данной задаче нарушена.\n\n### Масштабирование\n\nПри высоких нагрузках синхронизация задач может идти через Kafka: отдельные очереди для синхронизации полей (`task-sync-fields`) и файлов (`task-sync-files`), с dead-letter-очередями для проблемных сообщений. Consumer'ы полей поддерживают параллельную обработку (до 3 воркеров настраиваемой конкурентностью).\n\n### Текущий статус\n\nМодуль Task Sync находится в статусе BETA. В production на июнь 2026 года работает связка порталов `iridi.bitrix24.ru` ↔ `uhome.bitrix24.ru` с сопоставлением групп в обоих направлениях.\n\n## Кейсы внедрения\n\n### Кейс 1: Сервисная компания — техподдержка клиентов\n\n**Ситуация.** IT-интегратор обслуживает 20+ клиентов, у каждого свой портал Битрикс24. Заявки приходят в чаты на клиентских порталах, инженеры работают на портале интегратора.\n\n**До внедрения.** Переписка шла черезemail и Telegram. Инженеры не видели контекст заявки внутри CRM клиента. Среднее время ответа — 4 часа. 15% заявок терялись при передаче между каналами.\n\n**После внедрения.** Чат с ботом на каждом клиентском портале подключён к открытой линии интегратора. Инженер видит сообщение клиента в своей очереди, отвечает — ответ возвращается в клиентский чат. Время первого ответа сократилось до 20 минут. Потери заявок — 0.\n\n### Кейс 2: Строительный холдинг — два портала, одна команда\n\n**Ситуация.** Управляющая компания и стройплощадка работают в разных порталах. Прорабы на объекте пользуются одним порталом, проектный офис — другим. Задачи и чертежи нужно передавать между порталами по несколько раз в день.\n\n**До внедрения.** Файлы пересылались через WhatsApp. Задачи дублировались вручную. Сроки согласования документации — до 3 дней.\n\n**После внедрения.** Настроена связка чат↔чат между групповыми чатами порталов, включён перехостинг файлов. Чертежи и спецификации передаются с сохранением в хранилище принимающего портала. Срок согласования сократился до одного рабочего дня. Дублирование задач ушло благодаря Task Sync.\n\n### Кейс 3: Франчайзинговая сеть — головной офис и филиалы\n\n**Ситуация.** Франчайзер на своём портале, 10 франчайзи — каждый на своём. Нужен сквозной канал связи «франчайзи → поддержка головного офиса».\n\n**До внедрения.** Франчайзи звонили или писали в WhatsApp. Контекст обращений не фиксировался в CRM. Головной офис не имел статистики по типам обращений и времени решения.\n\n**После внедрения.** На каждом портале франчайзи настроен чат с ботом, подключённый к открытой линии головного офиса. Все обращения фиксируются в CRM, доступна история переписки, время ответа и решение. Руководитель поддержки видит отчёт по всем филиалам в едином интерфейсе.\n\n### Кейс 4: Проектный офис — синхронизация задач между порталами (Task Sync)\n\n**Ситуация.** Два портала: портал заказчика и портал подрядчика. Заказчик ставит задачи в своих проектах, подрядчик должен видеть их у себя.\n\n**До внедрения.** Задачи переносились через экспорт\u002Fимпорт CSV раз в неделю. При изменении задачи на одной стороне вторая оставалась неактуальной. 30% задач имели расхождения по статусу и срокам.\n\n**После внедрения.** Настроена связка порталов через Task Sync с сопоставлением проектных групп. Задачи синхронизируются инкрементально каждые 2 минуты. Расхождений по статусу — 0 (в пределах окна синхронизации). Экспорт задач отключён за ненадобностью.\n\n## Типичные ошибки при внедрении\n\n### 1. Ожидание, что user→user работает\n\nРежим пересылки сообщений между конкретными пользователями (`user → user`) временно отключён — и в интерфейсе, и на уровне валидации backend. При попытке выбрать получателем пользователя приложение не даст сохранить настройки. Правильный путь: использовать групповой чат или коллабу.\n\n### 2. Бот не добавлен в коллабу вручную\n\nДля коллаб API Битрикс24 не позволяет гарантированно добавить бота автоматически, как в обычный чат. Если не добавить бота вручную через интерфейс коллабы, сообщения маршрутизируются, но бот не сможет их доставить. Симптом: в логах трассировки видно, что маршрут отработал, а сообщение не появилось.\n\n### 3. Не включены нужные права для REST-методов\n\nПриложение требует доступ к `imbot`, `imconnector`, `im`, `tasks` и `task`. Если при установке не выданы все запрошенные права, часть функций не заработает. Проверка: после установки открыть карточку приложения в админке Битрикс24 и убедиться, что все скоупы активны.\n\n### 4. Не настроена очередь открытой линии\n\nПосле создания связки «клиент → открытая линия» сообщения падают в открытую линию, но если к ней не привязана очередь операторов — отвечать будет некому. Настройка очереди — зона ответственности администратора портала партнёра, приложение её не конфигурирует.\n\n### 5. Task Sync запущен без проверки сетевой доступности\n\nСинхронизация задач между порталами требует, чтобы backend-сервер приложения имел сетевой доступ к REST API обоих порталов. В коробочных версиях Битрикс24 это не всегда так: портал может быть за файрволом. Решение: белый список IP сервера приложения на обоих порталах или разворот приложения в одном сетевом контуре.\n\n## Сравнение с альтернативами\n\n### Штатный функционал Битрикс24\n\nШтатно Битрикс24 не предоставляет межпортальной пересылки сообщений. Можно создать общего пользователя на нескольких порталах и переключаться между ними, но это не решает задачу автоматической маршрутизации. Открытые линии работают только с внешними каналами (Telegram, WhatsApp, ВКонтакте), но не с другими порталами Битрикс24.\n\n### Ручная пересылка (email, мессенджеры)\n\nСамый распространённый «конкурент» приложения. Плюс: не требует настройки. Минусы: время, ошибки, отсутствие audit trail, невозможность синхронизации задач. При двух порталах и 20+ активных переписках в день ручной режим даёт потери на уровне 2–4 часов в день на сотрудника.\n\n### Другие приложения Маркетплейса\n\nНа момент написания статьи в Маркетплейсе нет приложения, которое одновременно решает задачи межпортальной переписки и синхронизации задач. Существуют решения для трансляции сообщений в Telegram из чатов Битрикс24, но они не покрывают сценарий «портал ↔ портал».\n\n### Самописное решение\n\nНаписать своего бота для пересылки сообщений через REST API imbot технически возможно. Однако потребуется решить те же проблемы, которые уже решены в «Межпортальных чатах 2.0»: дедупликация вебхуков, защита от эха, fallback-доставка, трассировка, синхронизация задач с conflict resolution, мобильная адаптация, управление ключами приглашений. Оценка трудозатрат — от 200 часов разработки и 50 часов поддержки в год. Приложение же устанавливается и настраивается за 1–2 часа.\n\n## FAQ\n\n**Можно ли связать больше двух порталов?**\nДа. Каждая связка настраивается попарно: портал А ↔ портал Б, портал А ↔ портал В и так далее. Ограничений по количеству связок нет.\n\n**Работает ли приложение на коробочном Битрикс24?**\nДа, при выполнении требований к версиям модулей: «Мгновенные сообщения» не ниже 26.250.0 и «Чат-боты Битрикс24» не ниже 26.50.0.\n\n**Нужен ли отдельный сервер?**\nДа, приложение требует собственный backend (FastAPI + PostgreSQL). Поставляется в Docker-контейнерах, разворачивается через Docker Compose. Может работать за nginx-прокси или на выделенном хосте.\n\n**Что с защитой данных?**\nСообщения передаются по HTTPS между порталами через backend приложения. Backend не хранит содержимое сообщений — только метаданные для трассировки. Файлы при перехостинге временно сохраняются и удаляются после передачи. Доступ к API порталов — через OAuth-токены, полученные при установке приложения.\n\n**Можно ли синхронизировать задачи без чатов?**\nДа, контур Task Sync не зависит от чатов. Можно настроить только связку порталов и сопоставление групп для синхронизации задач, не настраивая ботов и чаты.\n\n**Как понять, что сообщение не дошло?**\nВ приложении ведётся трассировочный лог потока сообщений: входящий вебхук → шаги маршрутизации → исходящие REST-вызовы → подтверждение доставки. По логам можно отследить путь любого сообщения и найти точку отказа.\n\n**Сколько времени занимает настройка?**\nБазовая связка «клиент → открытая линия» настраивается за 15–20 минут. Полный цикл с чат↔чат, файлами и Task Sync — 1–2 часа с учётом проверки всех сценариев.\n\n## SEO-блок\n\n**Высокочастотные:** межпортальные чаты, чат между порталами битрикс24, синхронизация чатов битрикс24, интеграция порталов битрикс24.\n\n**Среднечастотные:** межпортальная переписка битрикс24, связать чаты битрикс24, синхронизация задач между порталами, пересылка сообщений битрикс24, бот для связи порталов, открытая линия между порталами, task sync битрикс24.\n\n**Длинный хвост:** как связать два портала битрикс24 чатами, синхронизация задач между разными порталами битрикс24, переписка между филиалами битрикс24, межпортальные чаты 2.0, перехостинг файлов между порталами, коллабы межпортальная связь.\n\n## Заключение\n\n«Межпортальные чаты 2.0» решают конкретную инфраструктурную задачу: автоматическую передачу сообщений, файлов и задач между порталами Битрикс24 без дублирования, потерь и ручной работы. Приложение подходит компаниям, у которых два и более активных портала и есть устойчивый поток коммуникаций между ними.\n\nС чего начать: установите приложение в обоих порталах, создайте пробную связку «клиент → открытая линия» и проверьте прохождение сообщений в обе стороны. Затем расширяйте конфигурацию: добавьте чат↔чат-связки, настройте перехостинг файлов, при необходимости подключите Task Sync для синхронизации задач.\n\nРезультат оценивается по объективным метрикам: время прохождения сообщения между порталами (должно быть в пределах 2–5 секунд), отсутствие потерянных сообщений (проверяется по трассировочному логу), сокращение ручных операций по переносу информации (должно стремиться к нулю для настроенных связок).","\u003Ch1>Межпортальные чаты 2.0: единое пространство переписки для компаний с несколькими порталами Битрикс24\u003C\u002Fh1>\n\u003Ch2>Введение\u003C\u002Fh2>\n\u003Cp>Когда у компании два и более портала Битрикс24, переписка между ними превращается в ручную работу. Сотрудники копируют сообщения, пересылают файлы через сторонние мессенджеры, дублируют задачи в разных системах. На практике это означает, что до 30% рабочего времени поддержки и проектных команд уходит не на работу, а на перекладывание информации между порталами.\u003C\u002Fp>\n\u003Cp>Приложение «Межпортальные чаты 2.0» решает эту проблему на уровне инфраструктуры: оно связывает чаты разных порталов так, что сообщения, файлы и задачи передаются автоматически. Пользователи продолжают работать в привычном интерфейсе Битрикс24 — в чатах, открытых линиях и коллабах, — а приложение обеспечивает маршрутизацию, доставку и защиту от дублирования.\u003C\u002Fp>\n\u003Cp>В этой статье разберём, как устроена связка порталов, какие сценарии покрывает приложение, как работает синхронизация задач и какие ошибки допускают при внедрении.\u003C\u002Fp>\n\u003Ch2>Интеграция с CRM Битрикс24\u003C\u002Fh2>\n\u003Cp>Приложение устанавливается как стандартное приложение Маркетплейса и регистрирует собственный коннектор открытых линий с идентификатором \u003Ccode>swebs_chat_v_chat2\u003C\u002Fcode>. После установки в интерфейсе появляется два раздела: «Клиентский» и «Партнёрский» — каждый со своим набором настроек.\u003C\u002Fp>\n\u003Cp>В клиентском разделе настраиваются боты, которые будут принимать сообщения от пользователей и передавать их на портал партнёра. В партнёрском — открытые линии, боты-партнёры и связки с клиентскими порталами.\u003C\u002Fp>\n\u003Cp>Интеграция затрагивает следующие сущности Битрикс24:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Открытые линии (imconnector)\u003C\u002Fstrong> — приложение регистрирует коннектор, через который сообщения клиента попадают в очередь оператора на портале партнёра.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Чат-боты (imbot)\u003C\u002Fstrong> — боты v2 создаются и настраиваются через API, используются для маршрутизации сообщений между порталами.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Чаты и групповые чаты (im.chat)\u003C\u002Fstrong> — стандартные чаты Битрикс24, в которые добавляются боты для пересылки сообщений.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Коллабы (collab)\u003C\u002Fstrong> — поддержка коллаб как получателя сообщений добавлена в последних версиях; бот добавляется вручную пользователем.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Задачи (tasks.task)\u003C\u002Fstrong> — в контуре Task Sync создаются и синхронизируются задачи между порталами.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Приложение работает как в десктопной версии Битрикс24, так и в мобильном приложении. Для мобильных устройств реализовано адаптивное поведение: вместо нестабильных слайдеров используется прямой переход на страницы, что даёт предсказуемый UX.\u003C\u002Fp>\n\u003Ch2>Автоматизация межпортальной переписки\u003C\u002Fh2>\n\u003Ch3>Что заменяет приложение\u003C\u002Fh3>\n\u003Cp>До внедрения общение между порталами выглядит так: сотрудник на портале А пишет сообщение, делает скриншот или копирует текст, открывает сторонний мессенджер, пересылает коллеге на портале Б. Тот вручную создаёт задачу, прикрепляет файл, отвечает — и цикл повторяется в обратную сторону. При нескольких активных проектах между одними и теми же порталами эта механика множится и порождает ошибки: сообщение ушло не туда, файл потерялся, задачу забыли продублировать.\u003C\u002Fp>\n\u003Cp>После настройки приложения:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>сообщение, отправленное в чат с ботом на портале А, автоматически появляется в открытой линии или целевом чате на портале Б;\u003C\u002Fli>\n\u003Cli>ответ с портала Б возвращается в исходный чат портала А;\u003C\u002Fli>\n\u003Cli>файлы передаются вместе с сообщениями, с опциональным перехостингом на принимающий портал;\u003C\u002Fli>\n\u003Cli>дубликаты сообщений отсекаются на уровне вебхуков (защита от парных событий \u003Ccode>ONIMBOTMESSAGEADD\u003C\u002Fcode> \u002F \u003Ccode>ONIMBOTV2MESSAGEADD\u003C\u002Fcode>);\u003C\u002Fli>\n\u003Cli>петли эха при пересылке файлов между ботами блокируются до попадания в чат.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>Режимы маршрутизации\u003C\u002Fh3>\n\u003Cp>Приложение поддерживает три сценария маршрутизации:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\n\u003Cp>\u003Cstrong>Клиент → Открытая линия партнёра.\u003C\u002Fstrong> Классическая сервисная модель: клиент пишет в чат с ботом на своём портале, сообщение приходит в открытую линию на портале партнёра. Оператор отвечает — ответ возвращается клиенту. Подходит для техподдержки, аутсорсинговых колл-центров и сервисных компаний.\u003C\u002Fp>\n\u003C\u002Fli>\n\u003Cli>\n\u003Cp>\u003Cstrong>Чат ↔ Чат (бот ↔ бот).\u003C\u002Fstrong> Двусторонняя синхронизация между групповыми чатами. На обеих сторонах создаются боты, связываются между собой, и сообщения из одного чата автоматически попадают в другой. Подходит для проектных команд, работающих в разных порталах над общими задачами.\u003C\u002Fp>\n\u003C\u002Fli>\n\u003Cli>\n\u003Cp>\u003Cstrong>Коллаба как получатель.\u003C\u002Fstrong> Новый сценарий: сообщения маршрутизируются в коллабу на принимающей стороне. Бот добавляется в коллабу вручную — это ограничение API Битрикс24, а не приложения. После добавления бот полноценно участвует в переписке коллабы.\u003C\u002Fp>\n\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch3>Защитные механизмы доставки\u003C\u002Fh3>\n\u003Cp>Надёжность доставки обеспечивается эшелонированной логикой:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Дедупликация вебхуков\u003C\u002Fstrong>: парные события \u003Ccode>ONIMBOTMESSAGEADD\u003C\u002Fcode> (старый формат) и \u003Ccode>ONIMBOTV2MESSAGEADD\u003C\u002Fcode> (новый формат) приходят одновременно — приложение пропускает только одно.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Anti-echo защита\u003C\u002Fstrong>: если бот переслал файл и получил эхо собственного сообщения, оно не создаёт повторной пересылки.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Валидация payload\u003C\u002Fstrong>: перед отправкой проверяется \u003Ccode>BOT_ID\u003C\u002Fcode>, \u003Ccode>DIALOG_ID\u003C\u002Fcode>, согласованность с типом получателя (чат\u002Fколлаба).\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Fallback-отправка\u003C\u002Fstrong>: сначала используется \u003Ccode>imbot.v2.Chat.Message.send\u003C\u002Fcode>, при отказе — \u003Ccode>imbot.message.add\u003C\u002Fcode>.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>Пересылка файлов\u003C\u002Fh3>\n\u003Cp>Файлы передаются в одном из двух режимов:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Без перехостинга\u003C\u002Fstrong>: в сообщение вставляется ссылка на файл с портала-источника. Быстро, но требует доступа к исходному порталу.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>С перехостингом\u003C\u002Fstrong>: файл скачивается с портала-отправителя, загружается в хранилище портала-получателя и отправляется уже оттуда. Надёжно, но занимает время и требует дискового пространства.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Режим настраивается отдельно для каждой стороны связки флагами \u003Ccode>rehost_files_on_partner\u003C\u002Fcode> и \u003Ccode>rehost_files_on_client\u003C\u002Fcode>. Если перехостинг не удался, получатель видит уведомление о сбое вложения, а отправитель получает служебное сообщение об ошибке.\u003C\u002Fp>\n\u003Ch3>Создание задач из чата\u003C\u002Fh3>\n\u003Cp>Отдельный сценарий, не зависящий от синхронизации задач: при открытии placement «создать задачу из чата» пользователь заполняет форму (название, описание, срок) и задача создаётся на портале партнёра. Параметры назначения (группа и ответственный) берутся из настроек связки ботов.\u003C\u002Fp>\n\u003Ch2>Межпортальные задачи (Task Sync, BETA)\u003C\u002Fh2>\n\u003Cp>Контур синхронизации задач проектно отделён от механики чатов. Это самостоятельный модуль со своей логикой связывания и передачи данных.\u003C\u002Fp>\n\u003Ch3>Как работает\u003C\u002Fh3>\n\u003Col>\n\u003Cli>\n\u003Cp>\u003Cstrong>Связка порталов.\u003C\u002Fstrong> Партнёр генерирует ключ-приглашение (hash с TTL). Клиент вводит ключ в своём интерфейсе. В базе фиксируется связка порталов. Повторная активация обрабатывается идемпотентно.\u003C\u002Fp>\n\u003C\u002Fli>\n\u003Cli>\n\u003Cp>\u003Cstrong>Сопоставление групп.\u003C\u002Fstrong> Партнёр задаёт пары «группа партнёра → группа клиента». Для каждой пары включаются флаги: синхронизировать задачи и синхронизировать чат задачи.\u003C\u002Fp>\n\u003C\u002Fli>\n\u003Cli>\n\u003Cp>\u003Cstrong>Периодический синк.\u003C\u002Fstrong> Встроенный планировщик с настраиваемым интервалом (по умолчанию 120 секунд) инкрементально опрашивает изменения задач. Для каждой задачи ведётся зеркало: \u003Ccode>partner_task_id ↔ client_task_id\u003C\u002Fcode>. При конфликтах используется политика last-write-wins. Для предотвращения эха после обновления выставляются временные ignore-lock-окна.\u003C\u002Fp>\n\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>При потере зеркала задача помечается суффиксом \u003Ccode>tsync-off\u003C\u002Fcode> — это сигнал администратору, что синхронизация по данной задаче нарушена.\u003C\u002Fp>\n\u003Ch3>Масштабирование\u003C\u002Fh3>\n\u003Cp>При высоких нагрузках синхронизация задач может идти через Kafka: отдельные очереди для синхронизации полей (\u003Ccode>task-sync-fields\u003C\u002Fcode>) и файлов (\u003Ccode>task-sync-files\u003C\u002Fcode>), с dead-letter-очередями для проблемных сообщений. Consumer'ы полей поддерживают параллельную обработку (до 3 воркеров настраиваемой конкурентностью).\u003C\u002Fp>\n\u003Ch3>Текущий статус\u003C\u002Fh3>\n\u003Cp>Модуль Task Sync находится в статусе BETA. В production на июнь 2026 года работает связка порталов \u003Ccode>iridi.bitrix24.ru\u003C\u002Fcode> ↔ \u003Ccode>uhome.bitrix24.ru\u003C\u002Fcode> с сопоставлением групп в обоих направлениях.\u003C\u002Fp>\n\u003Ch2>Кейсы внедрения\u003C\u002Fh2>\n\u003Ch3>Кейс 1: Сервисная компания — техподдержка клиентов\u003C\u002Fh3>\n\u003Cp>\u003Cstrong>Ситуация.\u003C\u002Fstrong> IT-интегратор обслуживает 20+ клиентов, у каждого свой портал Битрикс24. Заявки приходят в чаты на клиентских порталах, инженеры работают на портале интегратора.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>До внедрения.\u003C\u002Fstrong> Переписка шла черезemail и Telegram. Инженеры не видели контекст заявки внутри CRM клиента. Среднее время ответа — 4 часа. 15% заявок терялись при передаче между каналами.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>После внедрения.\u003C\u002Fstrong> Чат с ботом на каждом клиентском портале подключён к открытой линии интегратора. Инженер видит сообщение клиента в своей очереди, отвечает — ответ возвращается в клиентский чат. Время первого ответа сократилось до 20 минут. Потери заявок — 0.\u003C\u002Fp>\n\u003Ch3>Кейс 2: Строительный холдинг — два портала, одна команда\u003C\u002Fh3>\n\u003Cp>\u003Cstrong>Ситуация.\u003C\u002Fstrong> Управляющая компания и стройплощадка работают в разных порталах. Прорабы на объекте пользуются одним порталом, проектный офис — другим. Задачи и чертежи нужно передавать между порталами по несколько раз в день.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>До внедрения.\u003C\u002Fstrong> Файлы пересылались через WhatsApp. Задачи дублировались вручную. Сроки согласования документации — до 3 дней.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>После внедрения.\u003C\u002Fstrong> Настроена связка чат↔чат между групповыми чатами порталов, включён перехостинг файлов. Чертежи и спецификации передаются с сохранением в хранилище принимающего портала. Срок согласования сократился до одного рабочего дня. Дублирование задач ушло благодаря Task Sync.\u003C\u002Fp>\n\u003Ch3>Кейс 3: Франчайзинговая сеть — головной офис и филиалы\u003C\u002Fh3>\n\u003Cp>\u003Cstrong>Ситуация.\u003C\u002Fstrong> Франчайзер на своём портале, 10 франчайзи — каждый на своём. Нужен сквозной канал связи «франчайзи → поддержка головного офиса».\u003C\u002Fp>\n\u003Cp>\u003Cstrong>До внедрения.\u003C\u002Fstrong> Франчайзи звонили или писали в WhatsApp. Контекст обращений не фиксировался в CRM. Головной офис не имел статистики по типам обращений и времени решения.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>После внедрения.\u003C\u002Fstrong> На каждом портале франчайзи настроен чат с ботом, подключённый к открытой линии головного офиса. Все обращения фиксируются в CRM, доступна история переписки, время ответа и решение. Руководитель поддержки видит отчёт по всем филиалам в едином интерфейсе.\u003C\u002Fp>\n\u003Ch3>Кейс 4: Проектный офис — синхронизация задач между порталами (Task Sync)\u003C\u002Fh3>\n\u003Cp>\u003Cstrong>Ситуация.\u003C\u002Fstrong> Два портала: портал заказчика и портал подрядчика. Заказчик ставит задачи в своих проектах, подрядчик должен видеть их у себя.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>До внедрения.\u003C\u002Fstrong> Задачи переносились через экспорт\u002Fимпорт CSV раз в неделю. При изменении задачи на одной стороне вторая оставалась неактуальной. 30% задач имели расхождения по статусу и срокам.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>После внедрения.\u003C\u002Fstrong> Настроена связка порталов через Task Sync с сопоставлением проектных групп. Задачи синхронизируются инкрементально каждые 2 минуты. Расхождений по статусу — 0 (в пределах окна синхронизации). Экспорт задач отключён за ненадобностью.\u003C\u002Fp>\n\u003Ch2>Типичные ошибки при внедрении\u003C\u002Fh2>\n\u003Ch3>1. Ожидание, что user→user работает\u003C\u002Fh3>\n\u003Cp>Режим пересылки сообщений между конкретными пользователями (\u003Ccode>user → user\u003C\u002Fcode>) временно отключён — и в интерфейсе, и на уровне валидации backend. При попытке выбрать получателем пользователя приложение не даст сохранить настройки. Правильный путь: использовать групповой чат или коллабу.\u003C\u002Fp>\n\u003Ch3>2. Бот не добавлен в коллабу вручную\u003C\u002Fh3>\n\u003Cp>Для коллаб API Битрикс24 не позволяет гарантированно добавить бота автоматически, как в обычный чат. Если не добавить бота вручную через интерфейс коллабы, сообщения маршрутизируются, но бот не сможет их доставить. Симптом: в логах трассировки видно, что маршрут отработал, а сообщение не появилось.\u003C\u002Fp>\n\u003Ch3>3. Не включены нужные права для REST-методов\u003C\u002Fh3>\n\u003Cp>Приложение требует доступ к \u003Ccode>imbot\u003C\u002Fcode>, \u003Ccode>imconnector\u003C\u002Fcode>, \u003Ccode>im\u003C\u002Fcode>, \u003Ccode>tasks\u003C\u002Fcode> и \u003Ccode>task\u003C\u002Fcode>. Если при установке не выданы все запрошенные права, часть функций не заработает. Проверка: после установки открыть карточку приложения в админке Битрикс24 и убедиться, что все скоупы активны.\u003C\u002Fp>\n\u003Ch3>4. Не настроена очередь открытой линии\u003C\u002Fh3>\n\u003Cp>После создания связки «клиент → открытая линия» сообщения падают в открытую линию, но если к ней не привязана очередь операторов — отвечать будет некому. Настройка очереди — зона ответственности администратора портала партнёра, приложение её не конфигурирует.\u003C\u002Fp>\n\u003Ch3>5. Task Sync запущен без проверки сетевой доступности\u003C\u002Fh3>\n\u003Cp>Синхронизация задач между порталами требует, чтобы backend-сервер приложения имел сетевой доступ к REST API обоих порталов. В коробочных версиях Битрикс24 это не всегда так: портал может быть за файрволом. Решение: белый список IP сервера приложения на обоих порталах или разворот приложения в одном сетевом контуре.\u003C\u002Fp>\n\u003Ch2>Сравнение с альтернативами\u003C\u002Fh2>\n\u003Ch3>Штатный функционал Битрикс24\u003C\u002Fh3>\n\u003Cp>Штатно Битрикс24 не предоставляет межпортальной пересылки сообщений. Можно создать общего пользователя на нескольких порталах и переключаться между ними, но это не решает задачу автоматической маршрутизации. Открытые линии работают только с внешними каналами (Telegram, WhatsApp, ВКонтакте), но не с другими порталами Битрикс24.\u003C\u002Fp>\n\u003Ch3>Ручная пересылка (email, мессенджеры)\u003C\u002Fh3>\n\u003Cp>Самый распространённый «конкурент» приложения. Плюс: не требует настройки. Минусы: время, ошибки, отсутствие audit trail, невозможность синхронизации задач. При двух порталах и 20+ активных переписках в день ручной режим даёт потери на уровне 2–4 часов в день на сотрудника.\u003C\u002Fp>\n\u003Ch3>Другие приложения Маркетплейса\u003C\u002Fh3>\n\u003Cp>На момент написания статьи в Маркетплейсе нет приложения, которое одновременно решает задачи межпортальной переписки и синхронизации задач. Существуют решения для трансляции сообщений в Telegram из чатов Битрикс24, но они не покрывают сценарий «портал ↔ портал».\u003C\u002Fp>\n\u003Ch3>Самописное решение\u003C\u002Fh3>\n\u003Cp>Написать своего бота для пересылки сообщений через REST API imbot технически возможно. Однако потребуется решить те же проблемы, которые уже решены в «Межпортальных чатах 2.0»: дедупликация вебхуков, защита от эха, fallback-доставка, трассировка, синхронизация задач с conflict resolution, мобильная адаптация, управление ключами приглашений. Оценка трудозатрат — от 200 часов разработки и 50 часов поддержки в год. Приложение же устанавливается и настраивается за 1–2 часа.\u003C\u002Fp>\n\u003Ch2>FAQ\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>Можно ли связать больше двух порталов?\u003C\u002Fstrong>\nДа. Каждая связка настраивается попарно: портал А ↔ портал Б, портал А ↔ портал В и так далее. Ограничений по количеству связок нет.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Работает ли приложение на коробочном Битрикс24?\u003C\u002Fstrong>\nДа, при выполнении требований к версиям модулей: «Мгновенные сообщения» не ниже 26.250.0 и «Чат-боты Битрикс24» не ниже 26.50.0.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Нужен ли отдельный сервер?\u003C\u002Fstrong>\nДа, приложение требует собственный backend (FastAPI + PostgreSQL). Поставляется в Docker-контейнерах, разворачивается через Docker Compose. Может работать за nginx-прокси или на выделенном хосте.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Что с защитой данных?\u003C\u002Fstrong>\nСообщения передаются по HTTPS между порталами через backend приложения. Backend не хранит содержимое сообщений — только метаданные для трассировки. Файлы при перехостинге временно сохраняются и удаляются после передачи. Доступ к API порталов — через OAuth-токены, полученные при установке приложения.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Можно ли синхронизировать задачи без чатов?\u003C\u002Fstrong>\nДа, контур Task Sync не зависит от чатов. Можно настроить только связку порталов и сопоставление групп для синхронизации задач, не настраивая ботов и чаты.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Как понять, что сообщение не дошло?\u003C\u002Fstrong>\nВ приложении ведётся трассировочный лог потока сообщений: входящий вебхук → шаги маршрутизации → исходящие REST-вызовы → подтверждение доставки. По логам можно отследить путь любого сообщения и найти точку отказа.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Сколько времени занимает настройка?\u003C\u002Fstrong>\nБазовая связка «клиент → открытая линия» настраивается за 15–20 минут. Полный цикл с чат↔чат, файлами и Task Sync — 1–2 часа с учётом проверки всех сценариев.\u003C\u002Fp>\n\u003Ch2>SEO-блок\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>Высокочастотные:\u003C\u002Fstrong> межпортальные чаты, чат между порталами битрикс24, синхронизация чатов битрикс24, интеграция порталов битрикс24.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Среднечастотные:\u003C\u002Fstrong> межпортальная переписка битрикс24, связать чаты битрикс24, синхронизация задач между порталами, пересылка сообщений битрикс24, бот для связи порталов, открытая линия между порталами, task sync битрикс24.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Длинный хвост:\u003C\u002Fstrong> как связать два портала битрикс24 чатами, синхронизация задач между разными порталами битрикс24, переписка между филиалами битрикс24, межпортальные чаты 2.0, перехостинг файлов между порталами, коллабы межпортальная связь.\u003C\u002Fp>\n\u003Ch2>Заключение\u003C\u002Fh2>\n\u003Cp>«Межпортальные чаты 2.0» решают конкретную инфраструктурную задачу: автоматическую передачу сообщений, файлов и задач между порталами Битрикс24 без дублирования, потерь и ручной работы. Приложение подходит компаниям, у которых два и более активных портала и есть устойчивый поток коммуникаций между ними.\u003C\u002Fp>\n\u003Cp>С чего начать: установите приложение в обоих порталах, создайте пробную связку «клиент → открытая линия» и проверьте прохождение сообщений в обе стороны. Затем расширяйте конфигурацию: добавьте чат↔чат-связки, настройте перехостинг файлов, при необходимости подключите Task Sync для синхронизации задач.\u003C\u002Fp>\n\u003Cp>Результат оценивается по объективным метрикам: время прохождения сообщения между порталами (должно быть в пределах 2–5 секунд), отсутствие потерянных сообщений (проверяется по трассировочному логу), сокращение ручных операций по переносу информации (должно стремиться к нулю для настроенных связок).\u003C\u002Fp>\n",1782217598374]