S-WEBS24

Битрикс24

CRM, процессы и приложения для вашей компании

Вернуться к списку Вернуться к статьям
Статьи

Системный пользователь Битрикс24: как понять, какие интеграции продолжают работать от его имени

Системный пользователь Битрикс24 обслуживает приложения и сохранённые интеграции. Чтобы понять, работает ли нужное подключение от его имени, начните с раздела «Разработчикам → Интеграции» и сопоставьте запись с назначением приложения. Служебный профиль не нужно добавлять в отдел или настраивать как обычного сотрудника.

Уведомление о создании системного пользователя при установке приложения
Пример установки стороннего приложения; это не экран интеграций S-WEBS. Из официальной справки Битрикс24: https://helpdesk.bitrix24.ru/open/28659338/

Когда появляется служебная учётная запись

Официальная инструкция описывает два случая: установка приложения из Маркетплейса и сохранение активных вебхуков при увольнении сотрудника. Во втором случае решение принимает администратор. При отключении вебхуков они перестают работать; при сохранении Битрикс24 создаёт системного пользователя с необходимыми правами.

У такого пользователя нет обычного логина и пароля. Профиль может отличаться отсутствием фотографии, незаполненной должностью и техническим адресом. Эти признаки помогают распознать служебную запись, но назначение доступа следует проверять по связанным интеграциям.

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

Начните с назначения интеграции

Для проверки нужен понятный ответ: что подключение читает или меняет и зачем оно продолжает работать. Составьте список бизнес-функций, а не список неизвестных технических имён.

Учебный пример: компания сохраняет передачу заявок из формы после смены интегратора. Важен результат «новая учебная заявка появляется в нужной CRM-карточке». Наличие служебной записи ещё не подтверждает этот результат и не объясняет, кому нужен доступ.

Что записать Зачем это нужно
Назначение подключения Отличить рабочий обмен от забытого эксперимента
Ответственный со стороны компании Знать, кто подтверждает необходимость доступа
Какие данные используются Проверить соответствие рабочей задаче
Контрольный сценарий Повторить проверку после кадрового изменения
Решение о сохранении или отключении Не полагаться на память прежнего специалиста

Не помещайте в такой список саму ссылку вебхука, токены или ключи. Для обсуждения достаточно безопасного названия записи и её назначения. Секрет доступа должен оставаться в принятом защищённом хранилище.

Как проверить системного пользователя без изменения настроек

  1. Попросите администратора открыть раздел интеграций.
  2. Найдите подключение по согласованному назначению.
  3. Сопоставьте его с обслуживающей служебной записью.
  4. Проверьте, есть ли владелец бизнес-процесса и понятный контрольный сценарий.
  5. Уточните, какие доступы действительно нужны подключению.
  6. Зафиксируйте результат инвентаризации, не меняя неизвестные интеграции одновременно.

Если запись не удаётся уверенно сопоставить, привлеките ответственного за приложение или обмен. Удаление профиля «для порядка» не должно быть способом проверки. В официальном описании системного пользователя отдельно сказано, что его не нужно удалять или добавлять в отделы.

Различайте доступ к обычной карточке сотрудника и полномочия интеграции. Перемещение служебной записи в отдел не заменяет проверку необходимых разрешений.

Что проверить при увольнении сотрудника

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

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

Порядок передачи рабочих данных описан в статье о сотрудниках и структуре компании. Здесь предмет уже: служебная учётная запись и продолжающийся доступ интеграций.

Как проверить, что нужная функция продолжает работать

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

Сравните результат с ожидаемым: правильный тип карточки, назначение, обязательные сведения и отсутствие лишнего изменения. При ошибке сначала проверьте конкретное подключение, его права и ответ внешней системы.

Не выдавайте сохранённую запись в списке за успешный обмен. И наоборот, один успешный запрос не доказывает, что все сценарии старой интеграции работают. В отчёте разделяйте «подключение найдено», «права проверены» и «контрольное действие выполнено».

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

Частые вопросы

Нужно ли создавать для системного пользователя пароль?

Нет. По официальному описанию у такой учётной записи нет обычного логина и пароля. Работа с ней отличается от приглашения сотрудника.

Будет ли приложение работать после увольнения установившего его сотрудника?

Штатная модель системного пользователя предназначена для продолжения работы приложения независимо от кадровых изменений. Реальный результат всё равно зависит от состояния самого приложения, выданного доступа и внешних систем; его проверяют отдельным сценарием.

Сохранение вебхука означает передачу всей работы новому сотруднику?

Нет. Оно сохраняет работу интеграции через служебную запись. Ответственных в CRM, задачи, доступ человека и передачу обязанностей нужно проверять отдельно.