Самая частая ошибка — думать, что перенос приложения из Маркета Битрикс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 поддержаны тарифом, а разработчик приложения не пишет о жесткой привязке к одному порталу. Хороший признак — когда в описании есть раздел про перенос или импорт/экспорт конфигурации.
Если видите фразы «привязка к порталу», «уникальный ключ активации на инстанс» или «данные хранятся на стороне поставщика и не переносятся» — готовьтесь перенастраивать нулями и восстанавливать только рабочие правила. В сложных случаях напишите в поддержку вендора: иногда они предоставляют технический перенос на новый портал по заявке.
Пошаговый чек-лист копирования без потери настроек
- Зафиксируйте текущие настройки. Скриншоты, выгрузка конфигов, список кастомных полей CRM с их ID, воронки и стадии, роботы/триггеры, вебхуки, Redirect URL, список подписок на события. Это база.
- Сравните тарифы и региональность порталов. Убедитесь, что нужные разделы доступны на целевом. Если нет — заранее апгрейд или замена механики.
- Получите все доступы. Админ‑права, платежные данные для повторной установки, OAuth доступ (для приватного), токены внешних сервисов.
- Подготовьте целевой портал. Создайте недостающие сущности: направления, стадии, кастомные поля, справочники, смарт‑процессы, открытые линии, формы. Имена можно скопировать, но ID будут другими — это нормально.
- Установите приложение из Маркета на целевой портал. Если это приватное решение — разверните новый экземпляр: добавьте домен целевого портала в Redirect URL, выпустите отдельную пару Client ID/Secret при необходимости.
- Импортируйте или вручную перенесите конфигурацию. Пропишите URL интеграций, ключи API, включите нужные опции. Сразу сопоставляйте поля: старые ID → новые ID.
- Пересоздайте подписки на события и вебхуки. В Битрикс24 это отдельные сущности: на новом портале их надо заново зарегистрировать, а в коде/настройках приложения обновить домен и секрет.
- Перепривяжите пользователей, роли и отделы. Маппинг делается по email/корп. ID, а не по внутренним числовым идентификаторам. Иначе роботы начнут ставить задачи «пустоте».
- Проверьте внешние сервисы. Белые списки IP, подписи вебхуков, callback URL, доменные политики DKIM/SPF (если есть отправка писем), номера телефонии и права на запись звонков.
- Прогоните тестовые сценарии на данных. Создание лида из формы, его авто‑распределение, конвертация в сделку, запуск роботов, генерация документа, запись звонка, синхронизация продукта — все по цепочке.
- Переключайте трафик поэтапно. Сначала пилотная группа 2–3 менеджера и неключевые каналы. Потом — полный перевод. Имейте «кнопку» отката: выключение роботов/подписок на старом портале и возврат DNS/трафика.
- Включите наблюдение. Логи ошибок, очередь событий, лимиты API, дубликаты сущностей. Первые 3–5 дней — повышенный мониторинг.
Какие данные и связи нужно перенастроить
В копии никогда не совпадают внутренние идентификаторы. Именно поэтому после установки нужно пройтись по завязкам и обновить ссылки на сущности. Если система настроена правильно, большая часть «сопоставления» делается через названия и коды, а не через «жесткие» ID.
| Сущность | Что сопоставить | Комментарий из практики |
|---|---|---|
| CRM поля (лид, контакт, сделка, смарт‑процессы) | Новые ID полей, типы, множественность | Чаще всего ломается логика роботов из‑за несовпадения типов (строка vs список) |
| Воронки и стадии | ID направлений и коды стадий | Названия совпадают, коды разные — обновляйте маппинг в настройках приложения |
| Пользователи/отделы/роли | Привязка по email/логину, а не ID | Хороший признак — когда в приложении есть маппинг по внешнему идентификатору |
| Открытые линии и формы | Новые идентификаторы каналов | Ссылки виджетов перегенерируйте, иначе лиды идут в «никуда» |
| Каталоги и товары | Справочники, свойства, валюты | Проверьте НДС/валюты, иначе ошибется расчет в документах |
| Подписки на события | Endpoint, секрет, список событий | Проверьте подтверждение подписки и ответы 200 ОК на колбеки |
| Внешние сервисы | Ключи, IP, списки рассылок, номера | Обычно забывают обновить белые списки и домены подписи |
Микро‑сценарий: вы перенесли приложение из Маркет Битрикс24, которое создает задачи при смене стадии. На новом портале стадия называется так же, но код другой. Робот молчит. Лечится заменой кода стадии в правилах приложения и перезапуском подписок.
Как проверить работу копии в отделе продаж
Тестируйте живыми операциями, но контролируемо. Создайте лид с сайта и из формы в чате, пропустите его через авто‑распределение, переведите по стадиям, зафиксируйте исходящий звонок и оплату. Если все отработало без ручных правок — вы близки к финишу.
Хороший признак — когда события в журнале идут без ретраев, дубликатов нет, а у менеджеров не всплывают «непонятные» ошибки прав. Еще проверяем: в задачах корректный ответственный, в сделках подставляются товары и суммы, документы генерируются, письма действительно уходят (а не висят в очереди), звонки прикрепляются к нужным сущностям.
Что смотреть при сбоях: если нет новых лидов — проверяйте активность виджетов и идентификаторы форм. Если не срабатывают роботы — сверяйте коды стадий и права на изменение сущности. Если «сыпятся» вебхуки — смотрите код ответа вашего endpoint и лимиты API. Обычно всплывает одна и та же ошибка: на тестах все работало, но после включения пилота достигли лимитов и начались таймауты. Решается батчированием запросов и очередями.
И напоследок. Зафиксируйте контрольные метрики до и после переноса: конверсия лид→сделка, среднее время до первого контакта, количество дублей в сутки. Это простой способ понять, что копия не только «завелась», но и не ухудшила процесс.
Готовы перенести приложение аккуратно и без простоев? Два шага: закажите экспресс‑аудит ваших интеграций и получите план переноса с маппингом сущностей. Если нужна помощь руками — обращайтесь в AMSALES: настройка автоматизаций и интеграций Битрикс24 https://amsales.ru/services/integracii/.
