Приказ оформили в 1С — учётная запись появилась в Яндекс 360: разбираем связку через входящий вебхук

Коротко

• Кадровое событие живёт в 1С: приказ о приёме или об увольнении оформляют там, а не в облаке.
• «+Альянс Поток» умеет принимать запрос из 1С входящим вебхуком. Это один из 18 типов триггеров сервиса (страница продукта, сверка 20.08.2026; то же число — в палитре интерфейса и в списке владельца проекта от 30.07.2026) и один из четырёх способов запустить сценарий (техническая документация продукта, 30.07.2026).
• По приказу о трудоустройстве сценарий заводит человека в Яндекс 360, по приказу на увольнение — снимает доступы, копирует данные и удаляет учётную запись последним шагом.
• Тело запроса может быть пустым, а ключа дедупликации у приёмника нет: два запроса по одному сотруднику — это два независимых запуска (владелец проекта, 20.08.2026).
• Ответ на вебхук означает факт запуска сценария, а не его успешное завершение. Результат смотрят в журнале запусков.

Актуальность фактов: август 2026 года. Тарифные лимиты сверены со страницей продукта 20.08.2026, механика — с технической документацией «+Альянс Потока» от 30.07.2026 и ответами разработчика от 03.08.2026.

С чего вообще начинается разговор про 1С

У любой компании, где кадры ведутся в 1С, есть развилка, и она не техническая. Где рождается кадровое событие? Формально — в приказе. Фактически — в письме кадровика администратору: «Иванов с понедельника, сделай почту».

В ИТ я больше двадцати лет и смотрю на такую развилку без иллюзий. Ручное звено между приказом и учётной записью — это не лень администратора, это отсутствие канала. Приказ есть, учётной записи нет, и между ними живой человек, который может заболеть, уйти в отпуск или просто не увидеть письмо до вторника.

Канал в «+Альянс Потоке» для такого обмена ровно один, и первым делом стоит понять, кто в нём говорит. Запрос отправляет 1С; сервис автоматизации ждёт. Компания «+Альянс» построила «+Альянс Поток» на платформе Яндекс 360, но команду в этой паре подаёт кадровая система: она знает про человека раньше облака.

Что такое входящий вебхук в «+Альянс Потоке»

Входящий вебхук — это триггер, который поднимает сценарий по HTTP-запросу извне, без события внутри Яндекс 360. Так он и описан в списке триггеров «+Альянс Потока» (владелец проекта, 30.07.2026): запуск извне HTTP-запросом, например из 1С.

Всего типов триггеров у сервиса 18 — число стоит в счётчике палитры интерфейса и подтверждено полным списком от владельца проекта (30.07.2026). Из них 15 — события платформы Яндекс 360 (новый сотрудник, блокировка, добавление в отдел и удаление из отдела, публикация файла на Диске и так далее) и 3 — собственные механизмы запуска «+Альянс Потока»: входящий вебхук, запуск из другого потока и запуск по расписанию. Плюс ручной старт как способ запуска. Итого четыре способа поднять сценарий: по событию платформы, по расписанию, входящим вебхуком и руками (техническая документация продукта, 30.07.2026).

Для интеграции с кадровой системой из этих четырёх подходит один. Событие платформы Яндекс 360 сработает только тогда, когда в облаке уже что-то произошло, — а нам нужно наоборот: сначала приказ, потом облако. Расписание не знает, когда приняли человека. Ручной старт возвращает нас к живому звену. Остаётся вебхук.

Направление обмена: приказ в 1С отправляет HTTP-запрос на входящий вебхук «+Альянс Потока», сценарий выполняет действия в Яндекс 360 — при приёме создаёт и настраивает учётную запись, при увольнении блокирует, отзывает сессии и удаляет её после копирования данных в «+Альянс Бэкап». Обратно в 1С уходит только факт запуска сценария (пунктирная стрелка).

Как выглядит связка по шагам

Порядок сборки для администратора выглядит так:

1. Подключить организацию к «+Альянс Потоку»: администратор авторизует приложение через Яндекс OAuth (техническая документация продукта, 30.07.2026). Роли в сервисе две — администратор и участник.
2. Собрать сценарий на визуальной доске: перетащить узлы, соединить связями, где нужно — добавить условие «если — иначе» или цикл. Программирование не требуется, интерфейс drag&drop (страница продукта, сверка 16.07.2026).
3. Поставить в начало сценария триггер «Входящий вебхук» вместо события платформы.
4. Настроить на стороне 1С отправку запроса. Момент отправки — при создании приказа или при его проведении — зависит от настроек самой 1С и остаётся на усмотрение инженера, который собирает обмен (владелец проекта, 20.08.2026). Это свойство кадровой системы, не сервиса автоматизации.
5. Прогнать сценарий тестовым запуском. В «+Альянс Потоке» есть тестовый прогон — проверка потока без реального события, с пошаговой трассировкой (техническая документация продукта, 30.07.2026).

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

Что сценарий делает с учётной записью

Кадровому обмену из всего каталога «+Альянс Потока» нужна одна группа — «Управление сотрудниками». Она закрывает весь путь учётной записи: создать, обновить, заблокировать, удалить, отозвать сессии и токены, перевести в отдел, добавить в группу. Семь действий из семнадцати, что есть в каталоге (техническая документация продукта, 30.07.2026).

Из этого набора собирается онбординг: создать учётную запись, дописать профиль, перевести в отдел, добавить в рабочие группы, отправить письмо с доступами через узел «Письмо (SMTP)». Значения между шагами передаются шаблонными переменными в фигурных скобках: в тексты, адреса и тела запросов подставляются данные события и результаты предыдущих узлов, поддерживаются вложенные пути, индексы массивов и обращение к заголовкам ответа — например {user_email} или {body.items[0].id} (техническая документация продукта, 30.07.2026).

Отдельно стоит группа «Резервное копирование» с двумя действиями: запустить бэкап пользователя и добавить пользователя в политику бэкапа. Между «+Альянс Потоком» и «+Альянс Бэкапом» реализована единая авторизация (разработчик, 30.07.2026), поэтому постановка нового сотрудника под регулярное копирование встаёт в тот же сценарий одним узлом, а не отдельной задачей на потом.

Приказ на увольнение: почему удаление стоит последним

Приказ об увольнении отправляется тем же каналом — входящим вебхуком из 1С (владелец проекта, 30.07.2026). А вот сценарий на приёмной стороне собран совсем иначе, и это главное место, где связку легко испортить.

Готовый шаблон «Увольнение сотрудника» в «+Альянс Потоке» состоит из четырёх шагов: согласование, бэкап пользователя, произвольное действие (в шаблоне это исходящий вебхук — сюда клиент подставляет своё, например задачу в Яндекс Трекере для HR) и только затем удаление сотрудника из тенанта Яндекс 360.

Порядок держится не на аккуратности сборщика, а на двух механизмах продукта. Первый — согласование: узел рассылает согласующим письмо с персональной ссылкой, поток приостанавливается до решения, и пока согласующие не ответили, бэкап не запускается. Кворум настраивается: «Нужны все согласующие» или «Достаточно любого». Второй механизм — гейтинг бэкапа: необратимые действия выполняются только после успешного завершения резервного копирования (техническая документация продукта, 30.07.2026). В шаблоне это видно и по подстановке — узел удаления берёт пользователя выражением {backup.uid}, то есть опирается на результат шага копирования.

И честная оговорка, которая экономит недели отладки. У платформы Яндекс 360 есть событие «Увольнение», и повесить оффбординг прямо на него выглядит красиво. Так делать нельзя: в этой системе увольнение и есть удаление учётной записи, событие наступает уже после удаления, а тогда полностью снять данные сотрудника не получится. Поэтому оффбординг поднимают либо руками, либо вебхуком из 1С — то есть до того, как в облаке что-то произошло.

Что означает ответ на вебхук

Место, где ломаются ожидания интегратора. Ответ на входящий вебхук означает факт запуска сценария — то, что система отработала на запрос. Завершение сценария — отдельное состояние: у «+Альянс Потока» есть статусы завершения (ошибка, успешная отработка и другие). Так это сформулировал владелец проекта 20.08.2026.

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

Что видно в записи о запуске (разработчик, 03.08.2026): статус, какой поток отработал, чем запущен, шаги с длительностью. Если в потоке есть бэкап — раскрываются его логи: название копии, время начала и завершения, счётчики «выполнено, пропущено, ошибок». У шага согласования остаётся факт пройденной ветки и список тех, кого ждут; момента решения и имени ответившего в записи нет, файл-основание из письма согласующим в истории не отображается. Выгрузки истории запусков в продукте нет — всё перечисленное смотрится глазами в интерфейсе.

Лимиты, которые считаются заранее

Вызовы вебхука тарифицируются, и арифметику лучше сделать до внедрения. Данные со страницы продукта, сверка 20.08.2026:

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

Границы связки: что знать до внедрения

Дедупликации у приёмника нет. Если по одному сотруднику пришли два запроса — это два независимых запуска потока, система их не связывает (владелец проекта, 20.08.2026). Отсюда прямое инженерное следствие: ключ идемпотентности живёт на стороне 1С. Кадровая система должна помнить, по какому приказу она уже отправляла запрос.

Тело запроса может быть пустым (владелец проекта, 20.08.2026). Минимальная сборка от этого выигрывает: 1С отправляет сигнал «приказ есть», а данные сотрудника сценарий берёт из Яндекс 360. Если же вы планируете передавать атрибуты в теле запроса, состав полей стоит уточнить до проектирования обмена: публичного описания формата у нас на эту дату нет, а гадать в ТЗ не надо.

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

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

И про статус, раз про импортозамещение спрашивают в каждом втором разговоре. «+Альянс Поток» в реестр российского ПО не внесён. Разработчик — компания «+Альянс», Россия; обработка данных ведётся на территории РФ (страница продукта, сверка 16.07.2026), сервис хранит данные только в собственной базе и на внешние сервисы автоматизации ничего не передаёт. Но записи в реестре у «Потока» нет, и выдавать одно за другое мы не будем. Из продуктов компании в реестр внесён «Мигратор T2T» (запись № 28672 от 09.07.2025).

Что проверить до того, как связка пойдёт в работу

Короткий список того, что стоит прогнать на стенде перед включением:

1. Провести один приказ дважды и посмотреть в журнале, сколько запусков получилось. Если два — ключ на стороне 1С обязателен.
2. Отправить запрос с пустым телом и убедиться, что сценарий поднимается.
3. Прогнать увольнение целиком: дождаться согласования, проверить в логах шага копирования счётчики «выполнено, пропущено, ошибок» и только потом смотреть на результат удаления.
4. Сложить пиковое число приказов за день и сравнить с лимитом вызовов вебхука своего тарифа.
5. Проверить, что 1С не считает ответ эндпоинта подтверждением выполнения.

Пробный период у «+Альянс Потока» — 30 дней бесплатно, без банковской карты (страница продукта, сверка 16.07.2026), этого хватает, чтобы пройти все пять пунктов на живых учётных записях.

Вопросы, которые задают чаще всего

Нужен ли программист, чтобы собрать связку 1С и Яндекс 360?

Со стороны «+Альянс Потока» — нет: сценарий собирается мышкой на визуальной доске, из готовых узлов, без написания кода. Со стороны 1С работа остаётся инженерной: нужно решить, в какой момент кадровая система отправляет запрос, и настроить отправку.

Что произойдёт, если приказ проведут дважды?

Поднимутся два независимых запуска сценария. Ключа дедупликации у приёмника входящих вебхуков нет, и связывать два запроса по одному сотруднику он не будет (владелец проекта, 20.08.2026). Защита от повторов строится на стороне 1С.

Можно ли повесить увольнение на событие «Увольнение» в Яндекс 360?

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

Ответ на вебхук подтверждает, что доступы сняты?

Нет. Ответ означает факт запуска сценария. Завершение — отдельное состояние со своими статусами; смотреть его нужно в журнале запусков «+Альянс Потока».

Можно ли выгрузить журнал запусков для акта или отчёта?

Нет, выгрузки истории запусков в продукте нет (разработчик, 03.08.2026). Данные о запуске видны в интерфейсе: статус, поток, триггер, шаги с длительностью, логи копирования.

Работает ли связка с чужой системой резервного копирования?

Встроенная связь у «+Альянс Потока» — с «+Альянс Бэкапом» (единая авторизация, запуск копии и добавление в политику). Другие системы резервного копирования подключаются как любая внешняя — через вебхуки (владелец проекта, 30.07.2026).

Сколько вызовов вебхука доступно на тарифе?

60 в час на поток на «Старте», 600 на «Бизнесе», 6 000 на «Корпоративном» (страница продукта, сверка 20.08.2026).

Александр Жогов, основатель и руководитель компании «+Альянс».