Практическое руководство

Как портал получает данные о сотрудниках

Как передавать данные сотрудников в портал: основной источник, идентификаторы, переводы, увольнения, исключения и сверка.

Материал WebexlabПодготовлено 4 мин чтения

Краткий ответ

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

Назначьте основной источник

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

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

Опишите события жизненного цикла

Опишите события жизненного цикла — сравнение
СобытиеИзменение в порталеКонтроль
ПриёмУчётная запись и подразделениеВерная принадлежность
ПереводНовые связи и полномочияОтзыв прежних исключений
Изменение контактаАктуальные сведенияСохранение идентичности
Завершение работыОграничение доступаСессии и открытые задачи

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

Выберите контракт обмена

SCIM описывает управление ресурсами идентичности через HTTP, включая пользователей и группы. Наличие стандарта не подтверждает его поддержку вашей системой: проверяют версию, расширения и фактические операции поставщика. Для другого API или файлового обмена также нужны правила изменения, удаления и обнаружения расхождений.

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

Учебный пример перевода руководителя

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

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

Согласуйте исправление расхождений

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

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

Поддерживайте сверку и ответственность

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

Приёмка охватывает создание, изменение, повтор, отключение и восстановление после ошибки. Единый вход проверяется отдельно: успешная синхронизация карточки не доказывает отзыв всех сессий. Готовый процесс сохраняет актуальные сведения и понятную ответственность за доступ на каждом этапе работы сотрудника.

Как отличить удалённого сотрудника от неполной выгрузки

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

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

Термины из материала

Источники и документация

У каждого документа указана дата последней проверки. Состав функций и интерфейсы сервисов могут меняться. Ссылки открываются в новой вкладке.

Следующий шаг

Применить к вашему проекту

Спроектируем обновление сотрудников и подразделений в портале с контролем изменений и исключений.

Обсудить задачу
Все материалы блога