Автоматизация бизнес-процессов с Power Automate — выбор между облачным потоком и потоком рабочего стола, проектирование обработки ошибок

«Каждое утро собирать CSV-файлы, накопившиеся в общей папке, сводить их в Excel и отправлять руководителю по почте». «Вручную копировать значения из нескольких учётных систем и сводить их в отчёт». В последнее время нам часто задают вопрос, можно ли автоматизировать подобные задачи с помощью Power Automate.

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

У Power Automate низкий порог входа: начать можно без кода или почти без кода. Именно эта простота часто приводит к тому, что поток попадает в продакшн раньше, чем продумано его проектирование. В этой статье мы разберём — в том порядке, в котором с этим обычно сталкиваются на практике, — различия между облачными потоками и потоками рабочего стола, разделение ролей с PowerShell и VBA, обработку ошибок, подходы к стабилизации UI-автоматизации, работу с учётными данными, governance и эксплуатацию, а также то, как понять момент, когда задача выходит за рамки возможностей Power Automate.

1. Сначала — выводы

• Power Automate делится на два больших направления: облачные потоки (соединяют облачные сервисы через коннекторы) и потоки рабочего стола (RPA, автоматизирующая экраны Windows и настольные приложения). Первое проектное решение — определить, какое из них действительно нужно.
• Если требуется просто автоматизировать «типовую задачу на ПК», во многих случаях в первую очередь стоит рассматривать PowerShell, а не Power Automate Desktop. Если клики и ввод на экране не обязательны, PowerShell зачастую проще поддерживать, и он легче ложится на систему контроля версий.
• Power Automate особенно оправдан, когда нужно управлять экраном существующей системы, для которой нет (или почти нет) API, либо когда требуется быстро собрать процессы уведомлений и согласования на коннекторах Microsoft 365 (Outlook, SharePoint, Teams и т. д.).
• Перед выводом в продакшн в проектирование стоит с самого начала заложить четыре вещи: обработку ошибок (On Block Error), стабилизацию UI-селекторов, безопасное управление учётными данными и governance через DLP-политики. Добавлять их постфактум — прямой путь к инциденту.¹²
• Для безучастного выполнения (unattended) нужна отдельная от выполнения на переднем плане (attended) лицензия и другие предпосылки. Если отложить проработку лицензирования на потом, легко получить ситуацию, когда поток работал в тестовой среде, но его невозможно запустить в продакшне.³⁴

2. Общая картина Power Automate

Power Automate — это не столько единый продукт, сколько платформа, объединяющая несколько механизмов автоматизации.

flowchart TB
    PA[Power Automate]
    PA --> Cloud[Облачные потоки]
    PA --> Desktop[Потоки рабочего стола / RPA]
    PA --> Process[Process mining]
    PA --> Builder[AI Builder]

    Cloud --> Auto[Автоматический поток<br/>по событию]
    Cloud --> Sched[Поток по расписанию<br/>периодический запуск]
    Cloud --> Instant[Мгновенный поток<br/>ручной запуск / кнопка]
    Cloud --> Connectors[Коннекторы<br/>SharePoint / Outlook / Teams / SQL и др.]

    Desktop --> Attended[На переднем плане attended<br/>запускается на глазах у пользователя]
    Desktop --> Unattended[Безучастно unattended<br/>на сервере/выделенном ПК]
    Desktop --> UIAuto[UI-автоматизация<br/>управление экраном, интеграция с существующими приложениями]

• Облачные потоки — это механизм, соединяющий облачные сервисы между собой через коннекторы. В зависимости от типа триггера они делятся на автоматические потоки (запуск по событию), потоки по расписанию (периодический запуск) и мгновенные потоки (запуск вручную).
• Потоки рабочего стола — это RPA (Robotic Process Automation), которая напрямую управляет приложениями и экранами Windows. Их можно вызывать из облачного потока или запускать самостоятельно.⁵
• Потоки рабочего стола далее делятся на выполнение на переднем плане (attended), которое запускается, когда пользователь сидит перед экраном, и безучастное выполнение (unattended), которое проходит без участия человека на выделенном ПК или сервере.⁴

«Выделенная машина» для безучастного выполнения — это не то же самое, что просто «незаблокированная». В Windows 10/11 безучастное выполнение завершится ошибкой, если сессия любого пользователя останется в заблокированном состоянии, независимо от того, чья это учётная запись, используемая для подключения. В Windows Server область действия немного уже: выполнение блокируется, только если заблокированная сессия принадлежит тому же пользователю, что используется для подключения. После обслуживания или после RDP-подключения другого администратора часто ограничиваются «блокировкой» или «отключением», но необходимо обязательно проследить, чтобы все вышли из системы («sign out»).⁶

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

3. Как выбирать между облачным потоком, потоком рабочего стола, PowerShell и VBA

Хотя всё это объединяет слово «автоматизация», сильные стороны у них весьма разные.

Частое заблуждение на практике — думать, что «нужна автоматизация → значит, нужен Power Automate». Если у системы уже есть API, а её всё равно хотят автоматизировать через UI-управление в Power Automate Desktop — это как раз тот случай, когда стабильнее вызывать API напрямую из PowerShell или .NET. И наоборот: если нужно управлять экраном старой учётной системы или Win32-приложения без API, UI-автоматизация потоков рабочего стола становится реалистичным выбором.

Дополнение: ограничения Excel и VBA, а также подходы к их замене, подробнее разобраны в отдельной статье «Что такое VBA — ограничения, перспективы, случаи, когда стоит заменить, и реалистичные паттерны миграции». Там же затронут паттерн сочетания Office Scripts и Power Automate для рабочих процессов на базе Microsoft 365.⁷

4. Разбираемся с лицензированием

Лицензии Power Automate в целом делятся на пользовательские лицензии и лицензии на уровне потока (процесса).³

Здесь всё немного запутано: то, какая лицензия применяется, определяется не тем, «кто создал поток», а тем, «как он выполняется». Автоматические потоки и потоки по расписанию работают в лицензионном контексте владельца потока, а мгновенные потоки, запускаемые по кнопке, — в лицензионном контексте вызвавшего их пользователя. Если проектирование изначально предполагает безучастное выполнение, лицензионные требования нужно проверить ещё на этапе проверки концепции — иначе есть риск застрять прямо перед переходом в продакшн. Отметим также, что прежняя надстройка «Unattended RPA add-on» теперь считается устаревшей и заменена лицензией Power Automate Process: существующие надстройки безучастного выполнения приравнены по статусу к лицензии Process, но для новых назначений нужно использовать именно лицензию Process.³⁸⁴

Важный момент: лицензии Process / Hosted Process сами по себе не заменяют пользовательскую лицензию. Чтобы назначить лицензию Process машине (это нужно для безучастного выполнения), машина должна быть заранее зарегистрирована пользователем с лицензией Power Automate Premium. Кроме того, при вызове потока рабочего стола — как на переднем плане (attended), так и безучастно (unattended) — из облачного потока пользователь, чьё подключение используется для выполнения, тоже должен обладать лицензией Premium (или другой лицензией с правом на потоки рабочего стола). Если ограничиться только закупкой ёмкости Process и упустить из виду необходимые пользовательские лицензии, всё упрётся уже на этапе функционального тестирования.³

5. Практический пример проектирования — свести CSV из общей папки в отчёт Excel и отправить по почте

В качестве конкретного примера возьмём распространённую задачу — формирование ежедневного отчёта.

Что нужно сделать

1. Собрать CSV-файлы за текущий день из общей папки
2. Свести данные и записать их в шаблон отчёта Excel
3. Сохранить отчёт в заданную папку
4. Отправить уведомление заинтересованным лицам по почте
5. При сбое уведомить ответственного и зафиксировать причину в логе

flowchart TD
    Start([Запуск по расписанию 06:30]) --> Block[[On Block Error: обработка агрегации]]
    Block --> List[List files in folder<br/>получить CSV за текущий день]
    List --> Check{Есть подходящие файлы?}
    Check -- Нет --> NoticeEmpty[Зафиксировать отсутствие файлов и завершить]
    Check -- Да --> Read[Read from CSV file<br/>цикл по файлам]
    Read --> Agg[Агрегировать значения в переменных]
    Agg --> Excel[Launch Excel<br/>открыть шаблон]
    Excel --> Write[Write to Excel worksheet<br/>записать результаты агрегации]
    Write --> Save[Сохранить и закрыть Excel]
    Save --> Mail[Send an email<br/>отправить отчёт ответственным]
    Mail --> Log[Дописать результат выполнения в лог-файл]
    Log --> End([Успешное завершение])
    Block -. ошибка .-> Handler[Обработчик ошибок]
    Handler --> CloseExcel[Закрыть Excel, если он остался открыт]
    CloseExcel --> LogErr[Зафиксировать ошибку в логе]
    LogErr --> Notify[Письмо администратору о сбое]
    Notify --> End2([Зафиксировано как аварийное завершение])

Основные действия и их роль:

Вместо того чтобы делать весь поток одним огромным списком действий, лучше разбить его на подпотоки — «получение файлов», «агрегация», «запись в Excel», «уведомление», «запись лога». Это облегчает последующие правки и повторный запуск отдельных частей. Конфигурация, при которой запуск по расписанию делает облачный поток, а фактическую обработку выполняет вызываемый им поток рабочего стола, тоже удобна в эксплуатации.⁵

6. Проектирование обработки ошибок

В Power Automate Desktop есть действие On Block Error, позволяющее задать единую обработку ошибок сразу для целого блока. Вместо того чтобы настраивать «поведение при ошибке» для каждого действия по отдельности, можно применить общую обработку ошибок ко всем действиям внутри блока.¹

[On Block Error] Блок обработки агрегации
  ├─ List files in folder
  ├─ Read from CSV file (цикл)
  ├─ Launch Excel / Write to Excel worksheet
  └─ Save Excel / Close Excel

[Обработчик ошибок]
  ├─ Действием Get last error получить содержимое ошибки (имя, место возникновения, соответствующее действие, подробное сообщение) в переменную
  ├─ Закрыть экземпляр Excel, если он остался открыт (именно при сбое нельзя пропускать уборку)
  ├─ Записать в лог действием Write text to file (Append)
  ├─ Уведомить администратора действием Send an email (V2)
  └─ Выбрать «продолжить с конца блока» или «остановить выполнение потока»

Здесь стоит обратить внимание на несколько моментов.

• Обработка ошибок отдельного действия имеет приоритет над обработкой на уровне блока, поэтому имеет смысл настраивать её индивидуально только для тех действий, где поведение действительно должно отличаться, а остальное отдавать под общий On Block Error.¹
• Опция «Retry action if an error occurs» позволяет автоматически повторять действие заданное число раз с заданным интервалом при временных ошибках — например, сетевых задержках или блокировке файла. Если делать повтор для всех ошибок без разбора, это только теряет время, поэтому стоит заранее разделить ошибки, для которых повтор имеет смысл, и те, для которых он не нужен (например, нарушения целостности данных).¹
• Чтобы обратиться к содержимому последней ошибки внутри обработчика, нужно явно добавить действие Get last error. Оно возвращает переменную с шестью свойствами возникшей ошибки — именем, местом, соответствующим действием, подпотоком, к которому та относится, деталями и сообщением; автоматически создаваемой неявной переменной для этого нет. Чтобы то же значение ошибки случайно не переиспользовалось позже, после получения безопаснее очистить его опцией «Clear error».¹
• В лог стоит записывать не только «успех/сбой», но и количество обработанных записей, имя целевого файла и текст сообщения об ошибке. Впоследствии единственная зацепка, помогающая понять, почему всё остановилось, — это именно лог.
• В качестве постобработки блока явно выбирается, «продолжить с конца блока» или «остановить выполнение потока». Если остановить поток при открытом экземпляре Excel, при следующем запуске может остаться висящий процесс — поэтому именно в момент ошибки важно не забывать про уборку (закрытие экземпляра).¹¹

Тем, кто привык к try/catch/finally в PowerShell, будет проще спроектировать этот механизм, если провести аналогию: «блок» On Block Error близок к try, обработчик ошибок — к catch, а последовательность уборки — к finally.

7. Стабилизация UI-автоматизации

Главная причина нестабильности потоков рабочего стола чаще всего кроется в способе идентификации UI-элементов — то есть в селекторе.

• По умолчанию UI element picker записывает элемент экрана как селектор — комбинацию атрибутов. Если в неё попадают атрибуты, чувствительные к обновлению приложения или изменению отображаемого содержимого (например, порядковые индексы или динамически генерируемые ID), поток может сломаться даже при внешне неизменном экране.¹²
• Если заменить Equals на Contains или регулярное выражение для атрибутов с изменяющимися значениями, а значения, зависящие от результата предыдущего действия, вынести в переменные, селектор становится более динамичным и устойчивым к поломкам.¹²
• Если настроить несколько селекторов, при сбое первого поток автоматически переключится на следующий. Для важных операций наличие резервного селектора заметно повышает стабильность.¹²
• Если селектор сломался, функция Repair selector может автоматически сгенерировать кандидатов на исправление. Прежде чем пересоздавать селектор вручную с нуля, стоит сначала попробовать её.¹²
• Переходы между экранами и запуск приложений занимают время, которое заранее не предсказать. Вместо того чтобы полагаться только на фиксированный Wait, стоит комбинировать действия условного ожидания — «дождаться окна», «дождаться появления UI-элемента» — и настроить автоматический повтор на случай, если элемент не найден сразу.¹³
• Для объектов автоматизации, которые в принципе не удаётся стабилизировать (виртуализированные экраны, экраны с часто меняющейся раскладкой и т. п.), не стоит цепляться за UI-операции — сначала лучше проверить, нет ли более стабильного способа интеграции: через API, обмен файлами или прямой доступ к базе данных.

Запустить UI-автоматизацию в первый раз само по себе несложно. А вот будет ли она работать без поломок и через полгода — это почти целиком определяется тем, как построены селекторы.

8. Безопасная работа с учётными данными

В автоматизации бизнес-процессов чаще всего проблемы возникают из-за работы с учётными данными — паролями, ключами API, строками подключения.

• Не стоит записывать пароли или сведения о подключении прямо в значения входных переменных потока. Действие Get credential позволяет безопасно получить учётные данные из «учётных данных Power Automate», за которыми стоит хранилище секретов — Azure Key Vault или CyberArk; полученное значение помечается как конфиденциальное и не попадает в лог выполнения потока.¹⁴¹⁵
• Если использовать Azure Key Vault как хранилище секретов, сведения о подключении к Key Vault можно централизованно вести на стороне Power Automate, не размазывая учётные данные по каждому отдельному потоку.¹⁵
• Для безучастного выполнения стоит завести отдельную учётную запись с минимально необходимыми правами, а не использовать ту, которой человек пользуется в повседневной работе. Чем шире права учётной записи, тем больше потенциальный ущерб от бага в потоке или ошибки настройки.
• Пароль, записанный открытым текстом во входную переменную «временно, чтобы просто заработало», имеет свойство доезжать в таком виде до продакшна. Безопаснее с самого начала тестирования выработать привычку пользоваться действием Get credential.

9. Governance и эксплуатация

Когда количество потоков, созданных отдельными людьми или командами, начинает расти, на первый план выходит контроль на уровне всей организации.

• Политики предотвращения потери данных (DLP) классифицируют коннекторы, доступные потокам и приложениям, как «только для бизнес-данных», «не для бизнес-данных» или «заблокировано», и не позволяют сочетать в одном потоке коннектор для бизнес-данных с коннектором, не предназначенным для них. Это первый уровень governance, который стоит выстроить, — он защищает от непреднамеренной утечки данных организации во внешний сервис.¹⁶
• Действия потоков рабочего стола тоже можно классифицировать и блокировать в рамках той же системы DLP-политик, но по умолчанию это не включено. В настройках клиента (tenant) Power Platform admin center нужно один раз включить параметр «Show desktop flow actions in DLP policies», причём отменить это включение впоследствии нельзя. Даже после включения под контролем оказываются только те модули и действия, которые явно классифицированы политикой, — поэтому наличие DLP-политики само по себе не означает, что под контролем находится весь набор потоков рабочего стола.²
• Машины для безучастного выполнения стоит объединять в группы машин и вести чёткий учёт того, какой поток на какой машине выполняется.
• Историю выполнения можно посмотреть в панели администрирования Power Automate и в разделе истории запусков. Если встроить в сам поток оповещение о сбое — уведомление в Teams или по почте, — сбой будет замечен без ручной проверки кем-то из сотрудников.
• Если облачному потоку нужно обратиться к локальному ресурсу — базе данных или файловому ресурсу внутри корпоративной сети, недоступному напрямую из облака, — используется шлюз данных для локальной среды (on-premises data gateway). Шлюзу не требуется открывать входящий порт со стороны облака: безопасный мост обеспечивается только исходящим соединением.¹⁷
• Разделение окружений (environments) на тестовое и продуктивное с раздельными потоками рабочего стола и сведениями о подключении для каждого окружения защищает продуктивные потоки от изменений, вносимых во время тестирования.

10. Границы Power Automate и критерии эскалации

Power Automate — мощный инструмент, но не универсальный. В следующих ситуациях стоит рассмотреть переход на PowerShell или приложение на .NET.

Когда ощущается, что «то, что делалось в Power Automate, разрослось и стало слишком сложным», зачастую разумнее не продолжать через силу расширять поток, а перейти к конфигурации, при которой основная логика выносится в .NET или PowerShell, а Power Automate занимается только запуском и уведомлениями — в итоге такой вариант оказывается проще в сопровождении. Практический пример автоматизации анализа логов и архивирования с помощью PowerShell приведён в отдельной статье «Прикладной PowerShell — безопасная автоматизация анализа логов, архивирования и отчётности».

11. Итог

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

Что выбрать — облачный поток или поток рабочего стола, и какие задачи лучше передать PowerShell или .NET. Если разобраться с этим заранее, объём переделок впоследствии заметно сокращается. Обработка ошибок, UI-селекторы, учётные данные, лицензирование и DLP-политики — всё это несравнимо дешевле заложить с самого начала, чем чинить постфактум, когда что-то уже сломалось. И то, хватит ли решимости, когда поток разрастётся и усложнится, не продолжать его расширять через силу, а вынести обработку в .NET или PowerShell, тоже во многом определяет, проживёт ли решение долго.

Именно такая разница в проектировании отделяет «поток, который просто работает» от «потока, которому можно спокойно доверять». Чем больше автоматизация завязана на существующие бизнес-системы и активы Excel/VBA, тем сильнее ранние проектные решения влияют на затраты на сопровождение в будущем.

Похожие статьи

• Что такое VBA — ограничения, перспективы, случаи, когда стоит заменить, и реалистичные паттерны миграции
• Прикладной PowerShell — безопасная автоматизация анализа логов, архивирования и отчётности
• Как реализовать вывод отчётов Excel — COM / Open XML / шаблоны

Смежные области консультирования

KomuraSoft LLC (合同会社小村ソフト) консультирует по поэтапной автоматизации и модернизации с сохранением существующих бизнес-активов на Excel, VBA и Windows, а также проводит ревью проектирования платформ автоматизации на базе Power Automate.

• Использование существующих активов и поддержка миграции
• Техническая консультация и ревью проектирования
• Разработка приложений для Windows
• Связаться с нами

Справочные материалы

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

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

Вопросы, которые часто возникают при консультациях по теме статьи.

Как выбирать между облачным потоком и потоком рабочего стола?

Облачный поток соединяет облачные сервисы между собой через коннекторы и хорошо подходит для процессов согласования, уведомлений, интеграции с SaaS и рабочих процессов вокруг Microsoft 365. Поток рабочего стола — это RPA, которая напрямую управляет приложениями и экранами Windows; это реалистичный выбор, когда нужно работать с экраном старой системы без API или с Win32-приложением. Начиная консультацию, полезно сразу разделить: речь о соединении облачных сервисов между собой или об управлении экраном — это заметно проясняет дальнейшее проектирование.

Что выбрать — Power Automate или PowerShell?

Если нужно просто автоматизировать типовую задачу на ПК, а клики или ввод на экране не обязательны, PowerShell обычно проще поддерживать, и он легче ложится на версионирование в Git. Управлять через UI системой, у которой уже есть API, в принципе менее стабильно, чем вызывать этот API напрямую из PowerShell или `.NET`. Обработка данных на сотни тысяч строк, сложная логика, требующая автотестов, и высокочастотные постоянно работающие процессы — тоже задачи для PowerShell или `.NET`. Если поток стал слишком сложным, вынесение основной логики наружу, при котором Power Automate занимается только запуском и уведомлениями, обычно облегчает сопровождение.

Какая лицензия нужна для безучастного (unattended) выполнения в Power Automate?

Для безучастного выполнения нужна отдельная от лицензии для выполнения на переднем плане (attended) лицензия — Power Automate Process, которая привязывается к потоку или машине, а не к пользователю. Прежняя надстройка для безучастного выполнения теперь считается устаревшей и заменена лицензией Process. При этом одной лицензии Process недостаточно вместо пользовательской: для регистрации машины нужен пользователь с лицензией Power Automate Premium. Кроме того, в Windows 10/11 безучастное выполнение завершается ошибкой, если у кого-либо осталась заблокированная сессия, поэтому нужно, чтобы все вышли из системы (sign out).

Из-за чего UI-автоматизация потоков рабочего стола становится нестабильной?

Чаще всего главная причина — способ идентификации UI-элементов, то есть селектор. Если в него попадают атрибуты, чувствительные к изменениям, например порядковые индексы или динамически генерируемые ID, поток может сломаться даже при внешне неизменном экране. Помогает следующее: заменить `Equals` на `Contains` или регулярное выражение для изменяющихся атрибутов, настроить несколько селекторов с автоматическим переключением на резервный при сбое первого, а при поломке селектора использовать функцию Repair selector для генерации кандидатов на исправление. Также важно не полагаться только на фиксированный `Wait`, а комбинировать его с действиями условного ожидания. То, будет ли автоматизация работать без поломок и через полгода, почти целиком определяется тем, как построены селекторы.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.