Лекция

Сценарий работает, а объяснить его некому

Ольга — no-code-специалист. За два года она собрала хозяйство, которое компания уже считает само собой разумеющимся: форма на сайте создаёт карточку в CRM, новая заявка падает сообщением в мессенджер дежурному, ночью выгрузка складывает вчерашние сделки в таблицу, по понедельникам уходит сводка руководителю. Всё это работает и не требует внимания. Ольга переходит в другую компанию и честно отрабатывает положенный срок.

Артём принимает хозяйство. Он открывает список сценариев и читает: «Интеграция 2 (новая) финал», «test», «Копия сценария 7», «Без названия». Что из этого живое, а что осталось от экспериментов — по списку не понять. Что сломается, если выключить любой из них, — тем более. Ольга за две недели пересказывает ему то, что успевает вспомнить, и это единственный носитель, который у Артёма есть.

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

Эта лекция не о том, как собирать сценарии: собирать вы умеете. Она о минимальном наборе записей, который делает собранное передаваемым. Записей семь, и ни одна из них не занимает больше страницы: паспорт сценария, правило имени, схема, журнал изменений, журнал решений, реестр и чек-лист передачи. Всё остальное — необязательная роскошь.

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

Чего эта лекция не делает

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

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

Не сравнивает платформы и не советует выбрать одну. Числа Make, n8n и Power Automate появляются здесь с одной целью: показать, что окно памяти платформы конечно и у всех разное. Это не рейтинг.

Не занимается управлением доступами. Единственное место, где лекция заходит на эту территорию, — вопрос о том, что нельзя писать в файл документации.

Тема 1 из 15 · Почему хозяйство сиротеет

«Осиротевший поток» — у этой аварии есть официальное имя

Ситуация Ольги и Артёма настолько типовая, что у неё есть термин в документации вендора. Microsoft называет это orphaned flow — осиротевший поток.

Определение из статьи поддержки

«An orphaned flow is a flow that no longer has a valid owner. These flows can fail if they use connections tied to that user account.»

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

Обратите внимание на вторую половину определения. Авария описана не как «сценарий потерялся» и не как «до него нет доступа». Она описана как отказ — сценарий продолжает существовать и продолжает запускаться, но в момент обращения к внешней системе выясняется, что обращаться не от кого.

Удаление учётной записи не удаляет сценарии

Оно делает их безымянными. Сценарии остаются на месте и остаются в расписании; пустеет только графа владельца. Искать такие потоки в центре администрирования Power Platform приходится глазами: раздел Resources → Flows, столбец Owners пустой. Если потоков много, список подгружается частями — кнопку Load more надо дожимать до конца, иначе часть хозяйства просто не попадёт в поле зрения. И видеть потоки без владельца может не любой сотрудник, а только тот, у кого есть соответствующие права.

То есть авария, которую вы ищете, по умолчанию невидима: её не показывает ни один экран, на который вы смотрите каждый день.

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

Чинится вручную, и чинить надо каждый сценарий

Через интерфейс лечение выглядит так: выбрать поток, нажать Share, ввести нового владельца, сохранить. Умножьте на число сценариев. Массово это делается административными средствами платформы: есть команды, которые получают список потоков, созданных конкретным пользователем, показывают текущие права и назначают совладельца; Microsoft приводит готовый цикл, перебирающий все потоки окружения и печатающий те, у кого не осталось ни одного живого владельца-пользователя. Это работа администратора, а не ваша, — но попросить его об этом должны вы, и до увольнения, а не после.

Компания хочет заранее застраховаться от осиротевших сценариев. Что даёт результат?
Осиротевший поток — проблема прав, а не знаний. Документация описывает механизм, но не выдаёт к нему доступ. Второй владелец и подключения на учётной записи, переживающей сотрудника, — единственное, что закрывает именно эту дыру.

Причина отказа — подключения, а не сценарий

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

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

Ольга перед уходом добавила Артёма как совладельца всех своих сценариев. Ночная выгрузка всё равно отказала после отключения её учётной записи. Почему?
Это ровно та причина отказа, которую называет определение осиротевшего потока: подключения привязаны к учётной записи. Передача сценария не переносит подключения — их создают заново или заранее переводят на учётную запись, которая не уходит вместе с человеком.
Бесплатный доступ

Дальше нужен аккаунт

Прогресс и монеты сохранятся.