Приказ подписали в 1С — и учётная запись сама появляется в Яндекс 360, без ручного письма кадровика. Разбираю, как «+Альянс Поток» ловит сигнал из 1С входящим вебхуком: заводит сотрудника при приёме и аккуратно сворачивает доступы при увольнении.
Коротко
- Кадровое событие живёт в 1С: приказ о приёме или об увольнении оформляют там, а не в облаке.
- «+Альянс Поток» умеет принимать запрос из 1С входящим вебхуком. Это один из 18 типов триггеров сервиса и один из четырёх способов запустить сценарий.
- По приказу о трудоустройстве сценарий заводит человека в Яндекс 360, по приказу на увольнение — снимает доступы, копирует данные и удаляет учётную запись последним шагом.
- Тело запроса может быть пустым. Чтобы назвать сотрудника, в теле передаётся идентификатор пользователя в 1С. Ключа дедупликации у приёмника нет: два запроса по одному сотруднику — это два независимых запуска.
- Ответ на вебхук означает факт запуска сценария, а не его успешное завершение. Результат смотрят в журнале запусков.
Ниже — как построить такую связку у себя: шаги сборки, место удаления в сценарии увольнения и пять проверок на стенде, которые стоит пройти до боевого запуска.
С чего вообще начинается разговор про 1С
У любой компании, где кадры ведутся в 1С, есть развилка, и она не техническая. Где рождается кадровое событие? Формально — в приказе. Фактически — в письме кадровика администратору: «Иванов с понедельника, сделай почту».
В ИТ я больше двадцати лет и смотрю на такую развилку без иллюзий. Ручное звено между приказом и учётной записью — это не лень администратора, это отсутствие канала. Приказ есть, учётной записи нет, и между ними живой человек, который может заболеть, уйти в отпуск или просто не увидеть письмо до вторника.
Канал в «+Альянс Потоке» для такого обмена ровно один, и первым делом стоит понять, кто в нём говорит. Запрос отправляет 1С; сервис автоматизации ждёт. Компания «+Альянс» построила «+Альянс Поток» на платформе Яндекс 360, но команду в этой паре подаёт кадровая система: она знает про человека раньше облака.
Что такое входящий вебхук в «+Альянс Потоке»
Входящий вебхук — это триггер, который поднимает сценарий по HTTP-запросу извне, без события внутри Яндекс 360. Отправляет такой запрос внешняя система — в нашем случае 1С.
Всего типов триггеров у сервиса 18. Из них 15 — события платформы Яндекс 360 (новый сотрудник, блокировка, добавление в отдел и удаление из отдела, публикация файла на Диске и так далее) и 3 — собственные механизмы запуска «+Альянс Потока»: входящий вебхук, запуск из другого потока и запуск по расписанию. Плюс ручной старт как способ запуска. Итого четыре способа поднять сценарий: по событию платформы, по расписанию, входящим вебхуком и руками.
Для интеграции с кадровой системой из этих четырёх подходит один. Событие платформы Яндекс 360 сработает только тогда, когда в облаке уже что-то произошло, — а нам нужно наоборот: сначала приказ, потом облако. Расписание не знает, когда приняли человека. Ручной старт возвращает нас к живому звену. Остаётся вебхук.
Направление обмена: приказ в 1С отправляет HTTP-запрос на входящий вебхук «+Альянс Потока», сценарий выполняет действия в Яндекс 360 — при приёме создаёт и настраивает учётную запись, при увольнении блокирует, отзывает сессии и удаляет её после копирования данных в «+Альянс Бэкап». Обратно в 1С уходит только факт запуска сценария (пунктирная стрелка).
Как выглядит связка по шагам
Порядок сборки для администратора выглядит так:
- Подключить организацию к «+Альянс Потоку»: владелец организации в Яндекс 360 авторизует приложение через Яндекс OAuth. Роли в сервисе две — администратор и участник.
- Собрать сценарий на визуальной доске: перетащить узлы, соединить связями, где нужно — добавить условие «если — иначе» или цикл. Программирование не требуется, интерфейс drag&drop.
- Поставить в начало сценария триггер «Входящий вебхук» вместо события платформы.
- Настроить на стороне 1С отправку запроса. Момент отправки — при создании приказа или при его проведении — зависит от настроек самой 1С и остаётся на усмотрение инженера, который собирает обмен. Это свойство кадровой системы, не сервиса автоматизации.
- Прогнать сценарий тестовым запуском. В «+Альянс Потоке» есть тестовый прогон — проверка потока без реального события, с пошаговой трассировкой.
Перед включением сценарий проходит валидацию графа: циклы, недостижимые узлы и некорректные связи проверяются автоматически, и невалидный поток не запускается вовсе. Это, на мой взгляд, важнее, чем кажется на этапе сборки: ошибку в связях вы увидите до того, как она доберётся до живой учётной записи.
Что сценарий делает с учётной записью
Кадровому обмену из всего каталога «+Альянс Потока» нужна одна группа — «Управление сотрудниками». Она закрывает весь путь учётной записи: создать, обновить, заблокировать, удалить, отозвать сессии и токены, перевести в отдел, добавить в группу. Семь действий из восемнадцати, что есть в каталоге.
Из этого набора собирается онбординг: создать учётную запись, дописать профиль, перевести в отдел, добавить в рабочие группы, отправить письмо с доступами через узел «Письмо (SMTP)». Значения между шагами передаются шаблонными переменными в фигурных скобках: в тексты, адреса и тела запросов подставляются данные события и результаты предыдущих узлов, поддерживаются вложенные пути, индексы массивов и обращение к заголовкам ответа — например {user_email} или {body.items[0].id}.
Отдельно стоит группа «Резервное копирование» с двумя действиями: запустить бэкап пользователя и добавить пользователя в политику бэкапа. Между «+Альянс Потоком» и «+Альянс Бэкапом» реализована единая авторизация, поэтому постановка нового сотрудника под регулярное копирование встаёт в тот же сценарий одним узлом, а не отдельной задачей на потом.
Приказ на увольнение: почему удаление стоит последним
Приказ об увольнении отправляется тем же каналом — входящим вебхуком из 1С. А вот сценарий на приёмной стороне собран совсем иначе, и это главное место, где связку легко испортить.
Готовый шаблон «Увольнение сотрудника» в «+Альянс Потоке» состоит из четырёх шагов: согласование, бэкап пользователя, произвольное действие (в шаблоне это исходящий вебхук — сюда клиент подставляет своё, например задачу в Яндекс Трекере для HR) и только затем удаление сотрудника из тенанта Яндекс 360.
Порядок в шаблоне «Увольнение сотрудника» держат два узла «+Альянс Потока», и оба стоят до удаления. Первый — согласование: узел рассылает согласующим письмо или сообщение в Яндекс Мессенджере с персональной ссылкой, поток приостанавливается до решения, и пока согласующие не ответили, бэкап не запускается. Кворум настраивается: «Нужны все согласующие» или «Достаточно любого». Второй — бэкап пользователя. Раз он стоит раньше удаления, действует гейтинг бэкапа: удалять сотрудника поток начнёт лишь тогда, когда копия успешно снята. В шаблоне это видно и по подстановке — узел удаления берёт пользователя выражением {backup.uid}, то есть опирается на результат шага копирования. Будете собирать свой сценарий вместо шаблона — бэкап перед удалением ставите вы, иначе копию удаление ждать не станет.
И честная оговорка, которая экономит недели отладки. У платформы Яндекс 360 есть событие «Увольнение», и повесить оффбординг прямо на него выглядит красиво. Так делать нельзя: в этой системе увольнение и есть удаление учётной записи, событие наступает уже после удаления, а тогда полностью снять данные сотрудника не получится. Поэтому оффбординг поднимают либо руками, либо вебхуком из 1С — то есть до того, как в облаке что-то произошло.
Что означает ответ на вебхук
Место, где ломаются ожидания интегратора. Ответ на входящий вебхук означает факт запуска сценария — то, что система отработала на запрос. Завершение сценария — отдельное состояние: у «+Альянс Потока» есть статусы завершения (ошибка, успешная отработка и другие).
Практический вывод для стороны 1С: отметку «доступы сняты» по ответу эндпоинта ставить нельзя. Ответ говорит «сценарий поднялся», а не «учётная запись удалена». Результат читается в журнале запусков.
В записи о запуске видно: статус, какой поток отработал, чем запущен, шаги с длительностью. Если в потоке есть бэкап — раскрываются его логи: название копии, время начала и завершения, счётчики «выполнено, пропущено, ошибок». У шага согласования остаётся факт пройденной ветки и список тех, кого ждут; момента решения и имени ответившего в записи нет, файл-основание из письма согласующим в истории не отображается. Выгрузки истории запусков в продукте нет — всё перечисленное смотрится глазами в интерфейсе. Что нужно для акта, переносите в него руками.
История запусков «+Альянс Потока» хранится, пока поток существует в системе. Поэтому сначала перенесите нужные записи в акт, а потом удаляйте поток.
Лимиты, которые считаются заранее
Лимит вызовов вебхука у каждого тарифа свой, и арифметику лучше сделать до внедрения. Сейчас цифры такие:
| Параметр | Старт | Бизнес | Корпоративный |
|---|---|---|---|
| Лимит вызовов веб-хука | 60 в час на поток | 600 в час на поток | 6 000 в час на поток |
| Активных потоков | 5 | 25 | ∞ (fair use) |
| Администраторов | 2 | 10 | ∞ |
| Подключённых организаций | 1 | 1 | 3 |
| Минимальный интервал запуска по расписанию | 15 минут | 5 минут | 1 минута |
Кадровые документы приходят неровно: в первый рабочий день месяца приказов может быть больше, чем за всю предыдущую неделю. Считать нагрузку по среднему за год — плохая идея, считать по пиковому дню — рабочая.
Границы связки: что знать до внедрения
Дедупликации у приёмника нет. Если по одному сотруднику пришли два запроса — это два независимых запуска потока, система их не связывает. Отсюда прямое инженерное следствие: ключ идемпотентности живёт на стороне 1С. Кадровая система должна помнить, по какому приказу она уже отправляла запрос.
Тело запроса может быть пустым. Так удобно проверить сам канал: 1С отправляет сигнал «приказ есть», и сценарий поднимается. О сотруднике в теле запроса передаётся идентификатор пользователя в 1С. Заложите его в ТЗ на обмен сразу.
Если упавший поток «+Альянс Потока» запустить повторно, он продолжит с точки сбоя и уже пройденные узлы заново не исполнит.
Одновременных запусков на организацию в «+Альянс Потоке» по умолчанию не больше 5. Ограничение зависит от тарифа. Если приказы у вас идут пачками, проверьте такую пачку на стенде до боевого запуска.
И про статус, раз про импортозамещение спрашивают в каждом втором разговоре. «+Альянс Поток» в реестр российского ПО не внесён. Разработчик — компания «+Альянс», Россия; обработка данных ведётся на территории РФ, сервис хранит данные только в собственной базе и на внешние сервисы автоматизации ничего не передаёт. Но записи в реестре у «Потока» нет, и выдавать одно за другое мы не будем. Из продуктов компании в реестр внесены «Мигратор T2T» (запись № 28672 от 09.07.2025) и «+Альянс Бэкап Яндекс 360» (запись № 35522 от 05.10.2026).
Что проверить до того, как связка пойдёт в работу
Короткий список того, что стоит прогнать на стенде перед включением:
- Провести один приказ дважды и посмотреть в журнале, сколько запусков получилось. Если два — ключ на стороне 1С обязателен.
- Отправить запрос с пустым телом и убедиться, что сценарий поднимается.
- Прогнать увольнение целиком: дождаться согласования, проверить в логах шага копирования счётчики «выполнено, пропущено, ошибок» и только потом смотреть на результат удаления.
- Посчитать приказы в самый загруженный час и сравнить с лимитом вызовов вебхука своего тарифа: лимит считается в час на поток. Если приказы идут пачками — отправить пачку и посмотреть в журнале, чем закончился каждый запуск.
- Проверить, что 1С не считает ответ эндпоинта подтверждением выполнения.
Пробный период у «+Альянс Потока» — 30 дней бесплатно, без банковской карты. Этого хватает, чтобы пройти все пять пунктов на живых учётных записях.
Вопросы, которые задают чаще всего
Нужен ли программист, чтобы собрать связку 1С и Яндекс 360?
Со стороны «+Альянс Потока» — нет: сценарий собирается мышкой на визуальной доске, из готовых узлов, без написания кода. Со стороны 1С работа остаётся инженерной: нужно решить, в какой момент кадровая система отправляет запрос, и настроить отправку.
Что произойдёт, если приказ проведут дважды?
Поднимутся два независимых запуска сценария. Ключа дедупликации у приёмника входящих вебхуков нет, и связывать два запроса по одному сотруднику он не будет. Защита от повторов строится на стороне 1С.
Можно ли повесить увольнение на событие «Увольнение» в Яндекс 360?
Технически такой триггер в каталоге есть, но для оффбординга с сохранением данных он не подходит: событие приходит уже после удаления учётной записи, и полный бэкап по нему не соберётся. Рабочие варианты запуска — ручной старт или входящий вебхук из 1С. Про то, что аудит-лог Яндекс 360 знает о новом сотруднике, но сам о нём не расскажет, есть отдельная статья.
Ответ на вебхук подтверждает, что доступы сняты?
Нет. Ответ означает факт запуска сценария. Завершение — отдельное состояние со своими статусами; смотреть его нужно в журнале запусков «+Альянс Потока».
Можно ли выгрузить журнал запусков для акта или отчёта?
Нет, наружу журнал не выгружается. Данные о запуске видны в интерфейсе: статус, поток, триггер, шаги с длительностью, логи копирования. Хранится история столько, сколько существует сам поток. Что при оффбординге попадает в журналы Яндекс 360, а что вписывают в акт руками, разобрано отдельно.
Работает ли связка с чужой системой резервного копирования?
Встроенная связь у «+Альянс Потока» — с «+Альянс Бэкапом» (единая авторизация, запуск копии и добавление в политику). Другие системы резервного копирования подключаются как любая внешняя — через вебхуки.
Сколько вызовов вебхука доступно на тарифе?
60 в час на поток на «Старте», 600 на «Бизнесе», 6 000 на «Корпоративном».
Александр Жогов, основатель и руководитель компании «+Альянс».
