Связь двух порталов Битрикс24 строится одним из трёх способов, в зависимости от задачи. Для переписки подходит канал Битрикс24.Network в контакт-центре. Для совместной работы над задачами с сотрудниками другой компании используют проекты с гостями. Для обмена сделками и контактами между CRM нужны вебхуки или готовое приложение из Маркета. Встроенной кнопки «объединить два портала» в облачном Битрикс24 нет.
Обычно с этим вопросом приходят в трёх ситуациях. Холдинг, где у каждого юрлица свой портал, а руководству нужна общая картина. Компания и её постоянный подрядчик или дилер, которым надо обмениваться заявками без пересылки таблиц по почте. И франшиза, где головной офис хочет видеть сделки партнёров. Решения для этих случаев разные, и путаница между ними стоит денег: иногда компании заказывают сложную синхронизацию CRM там, где хватило бы общего чата, и наоборот.
Нужно ли связывать порталы или лучше работать в одном
Прежде чем связывать порталы, стоит проверить, не проще ли перейти в один. Если компании принадлежат одному владельцу, работают с одной клиентской базой и одни и те же менеджеры ведут сделки обеих фирм, два портала создают больше проблем, чем решают: дубли контактов, двойная оплата лицензий, отчёты, которые приходится сводить вручную.
В одном портале разные направления разводят штатными средствами: отдельными воронками сделок, смарт-процессами, отделами в структуре компании и правами доступа. Сотрудник одной фирмы видит только свою воронку, а руководитель видит всё. На проектах B2BPRO.KZ мы чаще всего видим такую картину: второй портал завели «на время», для нового направления, а через год в нём уже сотни сделок, и объединять их дороже, чем было бы сразу настроить права.
Два портала оправданы, когда:
- компании юридически и финансово независимы, например вы и ваш дилер;
- данные одной компании не должны быть доступны другой даже администратору;
- у компаний разные тарифы, разные администраторы и разные сроки оплаты лицензий;
- один из порталов коробочный и стоит на своём сервере, а второй облачный.
Если ваш случай из этого списка, дальше выбирайте способ связи под задачу.
Как переписываться между порталами Битрикс24: канал Битрикс24.Network
Для переписки между порталами в Битрикс24 есть готовый инструмент: канал Битрикс24.Network в открытых линиях. Открытая линия — это очередь обращений в контакт-центре Битрикс24, куда падают сообщения из подключённых каналов и где их распределяют между сотрудниками.
Как это устроено, описано в справке Битрикс24 о канале Битрикс24.Network. Клиент или партнёр пишет вам в чат из своего Битрикс24, а сообщения приходят в вашу открытую линию. Чтобы он вас нашёл, вы отправляете ему специальную ссылку. Перейдя по ней, он видит список своих порталов и выбирает, из какого писать.
Порядок настройки:
- Откройте раздел «Контакт-центр» и нажмите на карточку «Битрикс24.Network».
- Выберите открытую линию, в которую будут приходить сообщения.
- Заполните поле «Имя»: его увидит собеседник в чате. Загрузите аватар, чтобы вас было легко узнать.
- Задайте приветственное сообщение и описание.
- При необходимости включите опцию «Разрешить параллельные диалоги с клиентом».
- Если канал будет использоваться в интеграциях, заполните поле «Код»: это идентификатор канала для работы через REST API.
- Скопируйте ссылку на канал и отправьте её партнёру.
Сильная сторона этого способа в том, что переписка идёт через открытую линию. Значит, работают распределение между сотрудниками, история диалогов и связь с CRM вашего портала. Ограничение тоже понятное: это только чат. Сделки, задачи и документы между порталами так не передаются.
Битрикс24.Network — это ещё и единый профиль пользователя, который объединяет все порталы, где он зарегистрирован или куда его пригласили. Поэтому сотрудник, который состоит в двух порталах, переключается между ними под одной учётной записью и не заводит отдельный логин для каждого.
Как работать над общими задачами с другой компанией: проекты с гостями
Для совместной работы над задачами с сотрудниками другой компании удобнее не связывать порталы, а пригласить людей гостями в проект. Гость — это внешний участник, который не входит в ваш Битрикс24: подрядчик, клиент, поставщик.
По справке Битрикс24 о приглашении гостей в проект, гость может общаться в чатах проекта, работать с задачами и участвовать во встречах, но доступа к остальной информации компании у него нет. Пригласить его можно двумя способами:
- Откройте главный чат проекта и нажмите кнопку в правом верхнем углу, затем перейдите на вкладку гостей.
- Введите номер телефона или электронную почту гостя и нажмите «Пригласить»: он получит SMS или письмо.
- Либо скопируйте ссылку-приглашение и отправьте её в мессенджере. Если ссылку нужно отозвать, её обновляют, и старая перестаёт работать.
Приглашения доступны только в уже созданном проекте. Проекты с гостями и аватары гостей в списке участников выделены зелёным, так что внешнего участника легко отличить от сотрудника. Проекты доступны на коммерческих тарифах.
Если вы раньше работали с внешними людьми через экстранет, учтите изменения. В ответах Битрикс24 на частые вопросы о коллабах и экстранет-группах сказано, что группы, коллабы и проекты объединены в один формат, а новые экстранет-группы создавать нельзя. Старые данные остаются доступными.
Для связки «заказчик и подрядчик» проект с гостями часто закрывает задачу целиком. Подрядчику не нужен ваш портал: он видит свои задачи и чат, а вы контролируете сроки. Синхронизация двух порталов здесь избыточна.
Как синхронизировать CRM между двумя порталами через вебхуки
Передавать сделки, лиды и контакты из одного портала в другой можно через вебхуки: исходящий вебхук в первом портале сообщает о событии, а входящий вебхук во втором создаёт запись. Вебхук — это адрес, через который внешняя система вызывает методы REST API Битрикс24 или получает уведомления о событиях.
Оба типа вебхуков создаются в разделе «Приложения» → «Разработчикам». Основные правила из документации REST API Битрикс24 о входящих и исходящих вебхуках:
- Запросы через входящий вебхук выполняются с правами сотрудника, который его создал. Если сотрудник видит не все сделки, вебхук тоже увидит не все.
- Исходящий вебхук отправляет POST-запрос на обработчик. Адрес обработчика должен быть публичным: localhost и самоподписанные SSL-сертификаты не подходят.
- Для проверки подлинности система выдаёт
application_token, и обработчик должен сверять его со значением из запроса. - В коробочной версии вебхуки требуют активной лицензии, а на демо-портале они недоступны.
Типовая схема передачи сделки выглядит так. В портале А настраивают исходящий вебхук на событие создания сделки ONCRMDEALADD, оно описано в справочнике событий CRM Битрикс24. В самом событии приходит только ID сделки, поэтому обработчик на вашем сервере запрашивает её поля через входящий вебхук портала А, приводит их к формату портала Б и создаёт сделку через входящий вебхук портала Б.
Звучит просто, но в такой интеграции есть несколько мест, где она ломается:
- Разные ID. Ответственный, стадия, источник и значения списочных полей в двух порталах имеют разные идентификаторы. Нужна таблица соответствий, и её придётся обновлять при каждом изменении настроек.
- Дубли контактов. Если перед созданием сделки не искать контакт по телефону или почте, в портале Б за месяц накопятся десятки копий одного клиента.
- Зацикливание. При двусторонней синхронизации сделка из А создаёт сделку в Б, та запускает событие и возвращается в А. Нужна метка источника, по которой обработчик пропускает «свои» записи.
- Потеря событий. Если обработчик недоступен в момент отправки, событие может потеряться. Для важных данных делают регулярную сверку по расписанию.
Такая интеграция требует сервера для обработчика и человека, который будет её сопровождать. Если нужно передавать только новые заявки в одну сторону, это день-два работы разработчика. Двусторонняя синхронизация с обновлениями полей — уже полноценный проект.
Готовые приложения из Маркета для связи порталов
Если писать свой обработчик не хочется, в Маркете Битрикс24 есть приложения сторонних разработчиков для связи порталов. В подборке приложений для миграции порталов в справке Битрикс24 перечислены, среди прочих, «Межпортальные задачи» для синхронизации задач, «Чат между порталами» и «Межпортальные чаты» для связки чатов, а также несколько миграторов для переноса данных между облаком и коробкой.
Перед установкой такого приложения проверьте несколько вещей:
- Кто разработчик и как долго приложение обновляется. Раздел отзывов в карточке приложения показывает, как быстро отвечают на проблемы.
- Какие права приложение запрашивает. Для синхронизации CRM ему нужен доступ к CRM обоих порталов.
- Как устроена оплата: подписка на каждый портал или одна на связку.
- Что происходит с данными при отключении: остаются ли созданные записи и как отменить синхронизацию.
Учтите, что это приложения сторонних разработчиков: за их работу отвечает автор приложения, а не Битрикс24. Если связка критична для бизнеса, заранее выясните, как быстро разработчик реагирует на сбои и есть ли у него техподдержка на русском языке в удобные для Казахстана часы.
Приложение быстрее собственной разработки, но вы зависите от чужого продукта. Если логика нестандартная, например сделка должна уходить в другой портал только на определённой стадии и с пересчётом суммы, готовое решение может не подойти.
Чем отличаются способы связи порталов Битрикс24
Выбор способа зависит от того, что именно должно переходить между порталами: сообщения, задачи или записи CRM. Сводная таблица:
| Задача | Инструмент | Что передаётся | Ограничения |
|---|---|---|---|
| Переписка с партнёром из его портала | Канал Битрикс24.Network в контакт-центре | Сообщения в открытую линию | Только чат, без сделок и задач |
| Общие задачи с подрядчиком | Проект с гостями | Чаты, задачи, встречи внутри проекта | Гость работает в вашем портале, его собственный портал не связывается |
| Передача заявок и сделок | Исходящий и входящий вебхуки | Любые данные CRM по вашей логике | Нужен сервер для обработчика и разработчик |
| Типовая синхронизация задач или чатов | Приложение из Маркета | То, что заложил разработчик приложения | Зависимость от стороннего продукта и его оплаты |
| Разовый перенос данных | Приложения-миграторы из Маркета | CRM, задачи, файлы по выбору | Это перенос, а не постоянная связь |
Пример: холдинг с двумя юрлицами и общим отделом продаж
Возьмём условный пример для иллюстрации. Холдинг в Алматы: торговая компания продаёт оборудование, сервисная компания его устанавливает и обслуживает. У каждой свой портал, свои бухгалтерия и администратор. Проблема в том, что после продажи менеджер пересылает данные клиента сервисной компании в мессенджере, и часть заказов теряется.
Решение собрали из двух частей:
- Когда сделка в портале торговой компании переходит на стадию «Оплачено», исходящий вебхук отправляет событие на небольшой обработчик. Тот забирает данные сделки и контакта и создаёт сделку в воронке «Монтаж» портала сервисной компании, предварительно проверив, нет ли уже такого контакта по телефону.
- Для вопросов по конкретным заказам менеджеры торговой компании пишут сервисному отделу через канал Битрикс24.Network, и переписка попадает в открытую линию сервисной компании с историей диалога.
Ответственного в новой сделке назначает обработчик по таблице соответствий: каждому менеджеру торговой компании соответствует координатор монтажа. Когда в одной из компаний меняется состав команды, администратор обновляет эту таблицу, и больше ничего перенастраивать не нужно.
Синхронизацию сделали односторонней: обратно в торговую компанию данные не возвращаются, статус монтажа менеджер при необходимости уточняет в чате. Это сознательное упрощение. Двусторонняя синхронизация стоила бы в разы дороже, а реальной потребности в ней не было.
Какие вопросы решить до начала интеграции
До любой технической работы нужно ответить на пять вопросов, и от ответов зависит, какой способ связи выбрать. Мы задаём их на первой встрече, и примерно в половине случаев после этого разговора объём работ сокращается.
- Что именно должно переходить между порталами? Сообщения, задачи, лиды, сделки, контакты, счета. Назовите конкретные сущности, а не «всё, что нужно».
- В какую сторону? Односторонняя передача в разы проще двусторонней. Если второй стороне нужно только получить заявку, обратная связь не нужна.
- В какой момент? При создании записи, при переходе на определённую стадию, раз в сутки. От этого зависит, какие события слушать.
- Кто владелец данных? Если клиент есть в обоих порталах и его телефон изменили в одном, должен ли он измениться в другом. Такие правила надо записать до разработки, иначе их придётся придумывать при первом конфликте.
- Кто будет сопровождать связку? Порталы меняются: добавляются поля, переименовываются стадии, увольняются сотрудники. У интеграции должен быть человек, который узнает о сбое раньше клиентов.
Отдельно продумайте доступы. Вебхук с правами администратора видит всю CRM портала, поэтому для межпортальной передачи лучше создать отдельную учётную запись с правами только на нужные воронки и сущности. Тогда даже при утечке адреса вебхука ущерб будет ограничен.
Частые ошибки при связке порталов
Большинство проблем с межпортальными интеграциями возникает не из-за техники, а из-за того, что заранее не договорились о правилах. Вот что мы встречаем чаще всего:
- Вебхук создан от имени уволенного сотрудника. Входящий вебхук работает с правами создателя, и после увольнения сотрудника интеграция может перестать работать. Создавайте вебхуки от служебной учётной записи администратора.
- Нет ответственного за интеграцию. Через полгода в портале меняют стадии воронки, и сделки перестают передаваться. Замечают это через месяц, когда клиенты начинают жаловаться.
- Синхронизируют всё подряд. Чем больше полей и сущностей передаётся, тем чаще ломается связка. Передавайте минимум, который реально нужен второй стороне.
- Вебхук с широкими правами в открытом доступе. Адрес входящего вебхука содержит секретный код. Если он попал в переписку или в код сайта, его нужно пересоздать.
Если нужна помощь с выбором схемы или с разработкой обработчика, посмотрите наши услуги по внедрению и настройке Битрикс24. Мы начинаем с вопроса, что именно должно переходить между порталами, и часто оказывается, что хватает чата и проекта с гостями, без программирования.
Хорошая проверка перед стартом любой интеграции: опишите на одной странице, какая запись, при каком событии и в какую воронку другого портала должна попасть, и кто отвечает за исправление, если она не попала. Если описание не помещается на страницу, задачу стоит упростить.
Частые вопросы
Можно ли объединить два портала Битрикс24 в один?
Встроенной функции объединения двух облачных порталов в Битрикс24 нет. Данные из одного портала можно перенести в другой с помощью приложений-миграторов из Маркета Битрикс24 или через REST API. После переноса второй портал обычно отключают. Перед миграцией стоит сверить воронки, поля и пользователей, иначе часть данных попадёт не туда.
Как написать сотруднику другой компании, если у него свой Битрикс24?
Проще всего подключить в контакт-центре канал Битрикс24.Network и отправить собеседнику ссылку на него. Он откроет ссылку, выберет свой портал и напишет вам прямо из своего Битрикс24. Сообщения придут в вашу открытую линию, где их примут сотрудники по обычным правилам распределения.
Можно ли дать подрядчику доступ к задачам без доступа к CRM?
Да, для этого подрядчика приглашают гостем в проект. Гость общается в чатах проекта, работает с задачами и участвует во встречах, но остальная информация компании ему недоступна. Пригласить его можно по телефону, почте или ссылке из главного чата проекта. Проекты работают на коммерческих тарифах Битрикс24.
Как передавать сделки из одного портала Битрикс24 в другой автоматически?
Автоматическую передачу сделок настраивают через вебхуки или готовое приложение из Маркета. В первом портале исходящий вебхук сообщает о событии, например о создании сделки, а обработчик на сервере создаёт сделку во втором портале через входящий вебхук. Для такой схемы нужен публично доступный обработчик и таблица соответствия полей двух порталов.
Будет ли связь работать между облачным и коробочным Битрикс24?
Да, вебхуки есть и в облачном, и в коробочном Битрикс24, поэтому связать их можно. В коробочной версии для вебхуков нужна активная лицензия, а сервер должен быть доступен из интернета для исходящих запросов. Часть приложений из Маркета тоже поддерживает связку облака и коробки, это указано в их описании.