Синхронизация задач между порталами Битрикс24: модуль «Межпортальные коммуникации»

Да, это одна из самых частых связок. Мы настраиваем мост, который компенсирует лимиты облачного API (используя очередь запросов), обеспечивая стабильный и быстрый обмен с коробочной версией, где ограничений на частоту запросов нет. Такая топология позволяет, например, головному офису работать в Облаке, а производству — на закрытой Коробке.

Да. Мы настраиваем фильтры на уровне вебхуков. Синхронизироваться будут только задачи из конкретных групп, проектов или помеченные определённым тегом. Остальные задачи останутся внутренними и не покинут периметр вашего портала. Это удобно, когда нужно связать только совместные проекты, не затрагивая внутренние процессы компаний.

Типовой проект синхронизации задач занимает от 10 до 20 рабочих дней. Сроки зависят от сложности маппинга полей, количества порталов, необходимости синхронизации файловых хранилищ и кастомных полей. В эту длительность входят аудит, разработка моста, тестовая связка, безопасный запуск на реальных данных и обучение ваших администраторов.

Абсолютно. Если мы используем коробочную версию, мост синхронизации разворачивается на вашем локальном сервере. Данные не покидают ваш периметр и не передаются на третьи стороны. Для облака используется защищённое HTTPS-соединение и OAuth 2.0. Все операции логируются, что упрощает прохождение внутренних и внешних аудиторских проверок.

В архитектуре Integrator.Digital предусмотрено разрешение конфликтов. По умолчанию приоритет отдаётся порталу-инициатору изменения или порталу Заказчика (это настраивается в ТЗ), чтобы избежать циклических обновлений и «залипания» задач. Система фиксирует метку времени каждого изменения и применяет жёсткие правила приоритетов.

Мост ведёт реестр перенесённых файлов. Если файл уже был синхронизирован, система не создаст его копию при повторном обновлении задачи. Файлы сверяются по надёжным идентификаторам, а не по случайным номерам. Это исключает появление «файловой каши» и версий вроде «финальный_финал_2», когда один и тот же документ копируется по кругу между порталами.

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

Да. Мы настраиваем передачу комментариев с привязкой к конкретным пользователям (при условии предварительного маппинга учётных записей). В чате задачи появляется понятное уведомление с пометкой, кто и с какого портала оставил комментарий. Служебные уведомления и технический шум при этом отфильтровываются — переносится только то, что действительно важно для второй команды.

Готовые приложения часто пропускают данные через свои промежуточные серверы, не имеют защиты от зацикливания и ограничены стандартными полями. Кастомный мост от Integrator.Digital разворачивается на вашем контуре (для Коробки), распознаёт «эхо» собственных действий, передаёт кастомные поля (UF_) и не требует ежемесячных подписок за каждого пользователя. Код остаётся в вашей собственности, а бизнес-логика настраивается под ваши процессы, а не под ограничения вендора.

Облачный Битрикс24 имеет жёсткий лимит: 2 запроса в секунду. При массовой синхронизации готовые приложения «падают», а данные теряются. В нашем мосте реализована «умная очередь» (Middleware): если портал-приёмник занят или лимит исчерпан, запросы встают в защищённую очередь и гарантированно доставляются позже. Система использует ретраи (повторные попытки) и детальное логирование, поэтому ни одна задача не теряется даже при пиковых нагрузках.

Перед запуском мы составляем карту маппинга — таблицу соответствия пользователей между порталами. Сопоставление может идти по корпоративному Email, табельному номеру, связке «ФИО + должность» или по специальному полю-идентификатору. Благодаря этому комментарий, оставленный Ивановым на Портале А, на Портале Б корректно отображается от имени Иванова, а не «неизвестного пользователя». При изменении сотрудников карту легко обновить без перенастройки всей интеграции.

Да. Мы настраиваем передачу любых пользовательских полей (UF_CRM_TASK, UF_DEAL, кастомные поля задач и т.д.). Например, если вы используете поля «Номер договора», «Сумма этапа», «Тип объекта» или «Код проекта» — все они будут зеркально отражаться на парном портале. Это критично для компаний, которые построили на кастомных полях свою бизнес-логику и отчётность.

Да. Иерархия задач полностью сохраняется: подзадачи, их ответственные, сроки и статусы переносятся на парный портал с сохранением структуры. Чек-листы внутри задачи также синхронизируются — отметки о выполнении пунктов видны обеим командам. Это позволяет работать с многоуровневыми проектами, где на одном портале ведётся общее управление, а на другом — детализация по этапам.

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

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