Заявки с сайта перестали попадать в CRM после ухода сотрудника. Или новый подрядчик получил доступ к порталу, но не знает, где работает обмен с учётной системой. В обоих случаях бизнес сталкивается с одной проблемой: интеграция настроена, а порядок её передачи никому не известен.
Такую зависимость лучше обнаружить до кадрового изменения. Ниже — рабочий план для руководителя и администратора: составить список связей, выбрать действие по каждой и проверить результат на понятном примере.
Что даёт системный пользователь Битрикс24
В сентябрьском обзоре Битрикс24, обновлённом 13 октября 2026 года, отдельно разобрали системного пользователя. Тема полезна компаниям, которые хотят сохранить работу подключённых сервисов при изменениях в команде.
По официальной справке служебная учётная запись создаётся при установке приложения Маркетплейса и при сохранении активных вебхуков увольняемого сотрудника. Связанные интеграции можно посмотреть в разделе «Разработчикам — Интеграции».
При этом для передачи всей системы одного действия в портале может оказаться недостаточно. У внешнего обмена есть собственные составляющие: сервер, настройки, доступ к другой системе, журнал ошибок и человек, который отвечает за поддержку.
Рассмотрим условную компанию, получающую обращения с сайта. Даже если связь со стороны CRM сохранилась, отправка заявок может зависеть от сайта, размещённого у прежнего подрядчика. Поэтому проверку стоит строить вокруг полного пути заявки.
Составьте список связей и владельцев
Начните с простого реестра. Для каждой связи запишите, какую задачу она решает и как понять, что она работает. Название приложения само по себе редко объясняет последствия отключения.
В карточку интеграции полезно включить:
- источник и получателя данных;
- какие записи передаются и что запускает обмен;
- где находится обслуживающий код или внешний сервис;
- кто управляет оплатой, размещением и доступами;
- кто получает сообщение об ошибке;
- к кому обращаться при сбое.
Не вставляйте в общий реестр секретные ссылки и ключи. Достаточно указать место их хранения и ответственного за доступ. При передаче документов отдельно проверьте, что у компании есть разрешённый доступ к необходимым материалам и настройкам.
Попросите уходящего специалиста пройти по одному обычному сценарию вслух: от действия клиента до записи в CRM. Это помогает найти ручные шаги, о которых не видно по списку подключений.
Выберите действие по каждому подключению
Сначала определите, какие связи остаются нужны, какие требуют замены и какие пора отключить. Автоматически сохранять всё подряд неудобно: вместе с полезным обменом можно оставить забытые подключения.
В инструкции по увольнению сотрудника описан выбор: отключить вебхуки или сохранить их на системном пользователе. Сохранение оставляет доступ по существующим ссылкам. Решение нужно принимать с учётом того, кому эти ссылки известны.
Для продолжающегося обмена согласуйте дальнейший порядок доступа. Если нужна замена секрета, заранее определите все места, где он используется, последовательность обновления и способ проверки. Иначе часть сервисов продолжит обращаться со старыми настройками.
Не включайте возможность входа бывшему сотруднику только ради исправления неизвестной зависимости. Сначала выясните конкретную причину сбоя и назначьте специалиста, который сможет устранить её с согласованным доступом.
Проверьте полный обмен и обработку ошибок
Для каждого важного сценария подготовьте контрольный пример с заранее известным ожидаемым результатом. Например: одно тестовое обращение с сайта должно создать одну запись в нужной воронке с правильным источником и ответственным.
Проверяйте не только наличие карточки. Сравните переданные поля, время события, владельца записи и то, не появились ли лишние копии. Если обмен идёт в обе стороны, отдельно проверьте обратное направление.
Полезно включить и нештатные ситуации:
- повторную отправку одного события;
- временную недоступность внешнего сервиса;
- изменение ответственного;
- отсутствие обязательного поля;
- исправление неудачной передачи.
Тесты проводите в согласованной среде и без нежелательных сообщений реальным клиентам. Состав проверок зависит от конкретной интеграции: часть возможностей придётся уточнить у разработчика, а недостающие механизмы — отдельно запланировать.
Как принять передачу и организовать поддержку
До завершения работ договоритесь, кто наблюдает за обменом и как команда узнаёт о проблеме. Фраза «всё работает» должна опираться на проверенные сценарии и доступный способ диагностики.
Условия тарифа и подписок проверяйте на конкретном портале. Например, справка Маркетплейса отдельно указывает требование подписки для REST API и вебхуков в зоне ru. Страна работы компании сама по себе не определяет условия её портала.
Передачу удобно завершать коротким перечнем результатов:
- подключения перечислены, по каждому принято решение;
- нужные доступы проверены;
- контрольные сценарии выполнены;
- ошибки и ограничения записаны;
- ответственный за поддержку назначен.
Если проблема затрагивает воронки и работу менеджеров, дополните проверку разбором ошибок при внедрении CRM.
Для обсуждения с QQDev подготовьте список интеграций, внешних систем и известных сбоев. Обратиться можно через страницу аудита Битрикс24. Такая подготовка помогает определить, где достаточно настройки, а где потребуется восстановление документации или доработка обмена.