000%
AMSALESзагрузка

Как скопировать приложение с Маркет Битрикс24

7 мин чтения
Как скопировать приложение с Маркет Битрикс24

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

Разобрал пошагово, как скопировать приложение с Маркет Битрикс24 без потери настроек, что проверить до старта и как убедиться, что копия реально работает в отделе продаж. Без теории, только применимые шаги.

Если коротко: сначала инвентаризация, потом права и подготовка среды, затем установка и ручное сопоставление сущностей, и только после — приемочные сценарии с реальными данными.

Что проверить перед копированием приложения

Определите тип: публичное приложение из Маркета или приватное (собственное) на OAuth. От этого зависит подход. Публичное вы «не копируете», а ставите заново на целевом портале и переносите настройки. Приватное — размножаете клиент (ID/secret), обновляете Redirect URL и пересобираете подписки на события.

Сверьте совместимость: тарифы обоих порталов, регион (RU/Global), облако vs коробка, версии модулей CRM и Контакт‑центра. Иногда приложение опирается на недоступные на младших тарифах места в интерфейсе (placements) или на закрытые API-методы. Обычно всплывает одна и та же ошибка — права кажутся «выданы», но нужных скоупов в токене нет, потому что тариф ниже.

Посмотрите, где хранятся данные. Часть вендоров держит свои настройки на стороне провайдера и привязывает их к ID портала. В таком случае «копирование приложения Битрикс24» означает повторную настройку и новое согласие с политикой доступа. Переноса истории данных может не быть — уточняйте заранее.

И еще один здравый шаг: проверьте, есть ли у приложения экспорт/импорт своих настроек. Некоторые решения позволяют выгрузить конфиг в JSON или загрузить из файла. Это экономит часы и снижает риск человеческой ошибки.

Какие права и доступы нужны для переноса

Без полного админдоступа на исходном и целевом порталах далеко не уедете. Нужны права «Администратор» с доступом к Маркету, к настройкам CRM (поля, направления, статусы), к автоматизациям и Купить/Продлить (если приложение платное). Для приватного приложения потребуется доступ к учетке разработчика и консоли, где видны Client ID/Secret и список доменов перенаправления.

Что нужно Зачем Где берется
Админ портала (источник/цель) Установка/удаление, доступ к CRM-структуре Владелец Битрикс24 или ИТ-администратор
Доступ к Маркету Повторная установка приложения из Маркета Права пользователя + платежные реквизиты (если платно)
OAuth учетка разработчика Клонирование приватного приложения, обновление Redirect URL Аккаунт разработчика/подрядчика
API-скоупы (crm, tasks, imopenlines и др.) Корректная работа методов и подписок на события Конфигурация приложения
Токены внешних сервисов Интеграции: рассылки, телефония, платежи ЛК провайдеров внешних сервисов

Микро‑сценарий: переносите интеграцию рассылок. Токен у маркетолога на личной почте, а IP‑белый список завязан на старый сервер. Итог — письма «отправлены», но по факту все в очереди. Решается передачей сервисного аккаунта на корпоративную почту и добавлением нового IP в белый список до переключения.

Как понять, что приложение можно копировать

Простой фильтр: приложение из Маркета доступно к установке на целевом портале, условия лицензии не запрещают вторую установку, нужные placements поддержаны тарифом, а разработчик приложения не пишет о жесткой привязке к одному порталу. Хороший признак — когда в описании есть раздел про перенос или импорт/экспорт конфигурации.

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

Пошаговый чек-лист копирования без потери настроек

  1. Зафиксируйте текущие настройки. Скриншоты, выгрузка конфигов, список кастомных полей CRM с их ID, воронки и стадии, роботы/триггеры, вебхуки, Redirect URL, список подписок на события. Это база.
  2. Сравните тарифы и региональность порталов. Убедитесь, что нужные разделы доступны на целевом. Если нет — заранее апгрейд или замена механики.
  3. Получите все доступы. Админ‑права, платежные данные для повторной установки, OAuth доступ (для приватного), токены внешних сервисов.
  4. Подготовьте целевой портал. Создайте недостающие сущности: направления, стадии, кастомные поля, справочники, смарт‑процессы, открытые линии, формы. Имена можно скопировать, но ID будут другими — это нормально.
  5. Установите приложение из Маркета на целевой портал. Если это приватное решение — разверните новый экземпляр: добавьте домен целевого портала в Redirect URL, выпустите отдельную пару Client ID/Secret при необходимости.
  6. Импортируйте или вручную перенесите конфигурацию. Пропишите URL интеграций, ключи API, включите нужные опции. Сразу сопоставляйте поля: старые ID → новые ID.
  7. Пересоздайте подписки на события и вебхуки. В Битрикс24 это отдельные сущности: на новом портале их надо заново зарегистрировать, а в коде/настройках приложения обновить домен и секрет.
  8. Перепривяжите пользователей, роли и отделы. Маппинг делается по email/корп. ID, а не по внутренним числовым идентификаторам. Иначе роботы начнут ставить задачи «пустоте».
  9. Проверьте внешние сервисы. Белые списки IP, подписи вебхуков, callback URL, доменные политики DKIM/SPF (если есть отправка писем), номера телефонии и права на запись звонков.
  10. Прогоните тестовые сценарии на данных. Создание лида из формы, его авто‑распределение, конвертация в сделку, запуск роботов, генерация документа, запись звонка, синхронизация продукта — все по цепочке.
  11. Переключайте трафик поэтапно. Сначала пилотная группа 2–3 менеджера и неключевые каналы. Потом — полный перевод. Имейте «кнопку» отката: выключение роботов/подписок на старом портале и возврат DNS/трафика.
  12. Включите наблюдение. Логи ошибок, очередь событий, лимиты API, дубликаты сущностей. Первые 3–5 дней — повышенный мониторинг.

Какие данные и связи нужно перенастроить

В копии никогда не совпадают внутренние идентификаторы. Именно поэтому после установки нужно пройтись по завязкам и обновить ссылки на сущности. Если система настроена правильно, большая часть «сопоставления» делается через названия и коды, а не через «жесткие» ID.

Сущность Что сопоставить Комментарий из практики
CRM поля (лид, контакт, сделка, смарт‑процессы) Новые ID полей, типы, множественность Чаще всего ломается логика роботов из‑за несовпадения типов (строка vs список)
Воронки и стадии ID направлений и коды стадий Названия совпадают, коды разные — обновляйте маппинг в настройках приложения
Пользователи/отделы/роли Привязка по email/логину, а не ID Хороший признак — когда в приложении есть маппинг по внешнему идентификатору
Открытые линии и формы Новые идентификаторы каналов Ссылки виджетов перегенерируйте, иначе лиды идут в «никуда»
Каталоги и товары Справочники, свойства, валюты Проверьте НДС/валюты, иначе ошибется расчет в документах
Подписки на события Endpoint, секрет, список событий Проверьте подтверждение подписки и ответы 200 ОК на колбеки
Внешние сервисы Ключи, IP, списки рассылок, номера Обычно забывают обновить белые списки и домены подписи

Микро‑сценарий: вы перенесли приложение из Маркет Битрикс24, которое создает задачи при смене стадии. На новом портале стадия называется так же, но код другой. Робот молчит. Лечится заменой кода стадии в правилах приложения и перезапуском подписок.

Как проверить работу копии в отделе продаж

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

Хороший признак — когда события в журнале идут без ретраев, дубликатов нет, а у менеджеров не всплывают «непонятные» ошибки прав. Еще проверяем: в задачах корректный ответственный, в сделках подставляются товары и суммы, документы генерируются, письма действительно уходят (а не висят в очереди), звонки прикрепляются к нужным сущностям.

Что смотреть при сбоях: если нет новых лидов — проверяйте активность виджетов и идентификаторы форм. Если не срабатывают роботы — сверяйте коды стадий и права на изменение сущности. Если «сыпятся» вебхуки — смотрите код ответа вашего endpoint и лимиты API. Обычно всплывает одна и та же ошибка: на тестах все работало, но после включения пилота достигли лимитов и начались таймауты. Решается батчированием запросов и очередями.

И напоследок. Зафиксируйте контрольные метрики до и после переноса: конверсия лид→сделка, среднее время до первого контакта, количество дублей в сутки. Это простой способ понять, что копия не только «завелась», но и не ухудшила процесс.

Готовы перенести приложение аккуратно и без простоев? Два шага: закажите экспресс‑аудит ваших интеграций и получите план переноса с маппингом сущностей. Если нужна помощь руками — обращайтесь в AMSALES: настройка автоматизаций и интеграций Битрикс24 https://amsales.ru/services/integracii/.

← Все статьи
Поделиться:

Хотите так же?

Начнём с бесплатной диагностики: покажем, где теряются деньги и как система продаж, AI и автоматизация ускорят рост.