KomuraSoft LLC
Связаться с нами
Меню

Создание процесса согласования в Power Automate — переводим бумажные и почтовые заявки в электронный вид

· · Power Automate, Процесс согласования, Облачный поток, Microsoft 365, Teams, SharePoint, Forms, Автоматизация бизнес-процессов, Заявка на согласование, Техническая консультация

«Мы распечатываем бланк заявки на согласование, ставим печать, передаём в соседний отдел — и он возвращается через неделю». «Отправляем Excel-форму заявки вложением по почте, а согласование — это ответное письмо со словами “ОК”». От компаний, уже перешедших на Microsoft 365, мы часто слышим просьбы навести порядок именно в таких процессах подачи заявок и согласования.

В Power Automate есть специальный механизм «Согласование» (Approvals), и зачастую можно построить процесс согласования — где от согласующего требуется лишь нажать кнопку в Teams или Outlook — целиком в рамках уже имеющейся лицензии, без дополнительных затрат. Но между «первый поток заработал» и «на это можно спокойно положиться в реальной работе» есть дистанция. Где остаются записи о согласовании? Что произойдёт, если согласующий просто оставит запрос без ответа? Кто исправит поток, если уволится человек, который его создал? В этой статье мы разберём базовые компоненты процесса согласования, проектные решения, на которых чаще всего спотыкаются на практике, и границу того, что стоит делать средствами Power Automate, а что — нет.

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

  • В основе согласования в Power Automate лежит действие «Начать и дождаться согласования». Доступно пять типов согласования: «требуется согласование всех», «первый ответ», «настраиваемые ответы» (всех/одного) и «последовательное согласование».1
  • Согласующий может ответить откуда угодно — из Teams, Outlook, портала Power Automate или мобильного приложения. Практически не нужно, чтобы кто-то осваивал новый интерфейс только ради согласования.23
  • Для приёма заявок реалистичны три варианта: Microsoft Forms, список SharePoint или приложение «Согласование» в Teams. Если позже понадобится сводный список и агрегация, стандартное решение — строить всё вокруг списка SharePoint.
  • Журнал выполнения потока по умолчанию виден лишь 28 дней, а одно выполнение обрывается по тайм-ауту не позднее чем через 30 дней. Не полагайтесь на журнал выполнения как на след согласования — с самого начала заложите запись результата, например, в список SharePoint.45
  • Увольнение или перевод владельца потока — главный операционный риск процесса согласования. Настройте совладельцев и продумайте, как обращаться с подключениями, ещё в день запуска потока в работу.6
  • Если пытаться реализовать «как есть» многоступенчатое согласование с обилием условных ветвлений, делегирование полномочий или регламент с жёсткими требованиями к аудиту, Power Automate перестаёт быть посильным в сопровождении. Это уже область специализированных систем документооборота или заказной разработки.

2. В чём проблема бумажного и почтового согласования

Больнее всего в согласовании бумажных заявок и Excel-форм, присланных по почте, не сами трудозатраты, а то, что «не видно состояния». Когда мы обсуждаем это с клиентами, почти всегда всплывают одни и те же три проблемы.

  • Непонятно, где сейчас всё застряло. Подавшему заявку не видно, на чьём столе лежит бланк или в каком почтовом ящике затерялось письмо. Напомнить получается только устно или по телефону, и тому, кому напоминают, это тоже неприятно.
  • Записи разбросаны. Следы согласования расходятся между бумажными шкафами и личными почтовыми ящиками. Чтобы для аудита или последующего запроса выяснить, «кто и когда согласовал ту заявку», приходится рыться в чужом почтовом ящике. А если сотрудник увольняется, вместе с ним исчезает и его ящик.
  • Невозможно отследить возврат на доработку. Когда отказ или просьба доработать передаются устно или письмом, путаница возникает уже в том, к какой версии заявки относилось замечание. Стоит переслать исправленный вариант — и согласование снова начинается с самого начала.

Практически все эти проблемы решаются тем, что «состояние заявки и её запись собираются в одном месте». А если Microsoft 365 уже внедрён, то и место хранения (SharePoint), и канал уведомлений (Teams/Outlook), и средство автоматизации (Power Automate) уже под рукой.

3. Базовые компоненты согласования в Power Automate

Действие «Начать и дождаться согласования»

В центре процесса согласования — действие коннектора «Согласование» (Approvals) «Начать и дождаться согласования» (Start and wait for an approval). Вы указываете заголовок запроса, детали и согласующих, и на этом шаге поток останавливается, дожидается ответа согласующего и лишь после этого переходит к следующему действию.1

Существует пять типов согласования.1

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

С помощью настраиваемых ответов можно определить не привычную пару «согласовать/отклонить», а, например, варианты «согласовать», «вернуть на доработку», «отложить». Это станет строительным блоком для цикла возврата на доработку, о котором пойдёт речь ниже.

Отметим, что для использования функции согласования нужна база данных Microsoft Dataverse. Записи запросов и ответов сохраняются в Dataverse, а в среде по умолчанию она автоматически создаётся при первом создании потока согласования, так что обычно об этом даже не приходится задумываться. Коннектор «Согласование» — стандартный, поэтому создать поток согласования можно на любой лицензии, дающей доступ к стандартным коннекторам (например, Office 365).1

Откуда согласующий может ответить

Запрос на согласование доходит до согласующего по электронной почте и через мобильное приложение Power Automate.3 В Outlook приходит аккуратно оформленное письмо с согласованием, из которого можно сразу ответить.7 Согласование, адресованное отдельному пользователю, также приходит уведомлением в Teams, откуда можно согласовать, отклонить или оставить комментарий — из чата или из приложения «Согласование».2 Отсутствие барьера «нужно залогиниться на специальном сайте, чтобы согласовать» — главная причина, почему процессы согласования действительно приживаются.

Есть один нюанс. Если адресовать согласование группе Microsoft 365, уведомление в Teams не отправляется. Уведомления в Teams приходят только для согласований, адресованных отдельному пользователю.8

Общая схема потока

На примере заявки на закупку общая схема выглядит так.

Teams / Outlook / мобильноеСогласованоОтклонено/на доработкуТайм-аутУсловие триггера запускаеттолько «повторную подачу»Заявитель вводит данныеотправка Forms / запись в список SharePointЗапуск облачного потокатриггер нового ответа/добавления элементаЗапись заявки в список SharePointстатус: ожидает согласованияНачать и дождаться согласованияотправка запроса согласующемуОтветОбновить статус списка на «Согласовано»записать согласующего, дату/время, комментарий в столбцыОбновить статус на «На доработке»уведомить заявителя о причинеНапоминание / эскалацияУведомить заявителя о результатеЗаявитель дорабатывает и подаёт повторно

Ключевой момент — то, что шаг «запись» вставлен и до, и после действия согласования. Почему именно так, объясним в главе 5.

4. Как спроектировать приём заявок

Удобство процесса согласования определяется не столько стороной согласования, сколько приёмом ввода на стороне заявителя. Реалистичных вариантов три.

Критерий Microsoft Forms Список SharePoint Приложение «Согласование» в Teams
Удобство ввода Проще всего — формат формы. Легко заполнять и со смартфона Форма ввода списка. При большом числе столбцов немного громоздко Прямо из чата или приложения Teams. Создавать поток даже не требуется9
Учёт заявок и управление статусом Слабое (есть список ответов, но нет столбца статуса) Сильное — столбцы, представления и управление статусом это именно его профиль Только список отправленного/полученного внутри приложения
Интеграция с потоком Через пару «триггер “при отправке нового ответа”» + «получить сведения об ответе»10 Через триггер создания/обновления элемента — типовая конфигурация из учебника по согласованию3 Типизация через функцию шаблонов. Гибкость на стороне потока невысокая
Вложения Возможны через вопрос с загрузкой файла Естественно комбинировать вложение к элементу с библиотекой документов К запросу на согласование можно прикрепить файл
Подходящие случаи Мало полей заявки, приоритет — простота ввода. Первый шаг замены существующей Excel-формы Хочется вести реестр заявок, большой объём, нужна последующая агрегация Разовые согласования, не заслуживающие типизации (например, разовое подтверждение у руководителя)

Вот примерный ориентир для выбора.

  • Если нужно просто перевести в электронный вид разовые согласования, потока можно вообще не создавать — достаточно приложения «Согласование» в Teams. Оно позволяет отправить запрос на согласование прямо из чата; работает на платформе Power Automate, но создание потока не требуется.9
  • Если цель — заменить бланк заявки, быстрее всего использовать Forms как приём, принимать ответы потоком и направлять их на согласование. Есть и готовый шаблон, который подставляет содержимое ответа Forms прямо в запрос на согласование.11
  • Если нужно вести реестр заявок, стройте всё вокруг списка SharePoint. Даже если входной точкой служит Forms, достаточно в начале потока перенести ответ в список — и столбец статуса (ожидает согласования/согласовано/на доработке) вместе с представлением сделают «где сейчас всё застряло» видимым для всех. По сути, именно здесь и находится ответ на проблемы бумажного и почтового согласования, названные в начале статьи.

Для небольшого старта удобна конфигурация «принимать через Forms, записывать в список SharePoint и туда же записывать результат согласования» — она одновременно даёт простоту ввода и ведение реестра.

5. Проектные решения, которые реально работают на практике

Где хранить записи о согласовании — не полагайтесь на журнал выполнения

Это самое важное проектное решение. Журнал выполнения потока по умолчанию отображается только 28 дней.4 Для потока, включённого в решение (solution), метаданные журнала выполнения можно сохранять в Dataverse, но и там срок хранения по умолчанию — 28 дней, а изменить его может администратор.12

Иными словами, практика выяснять постфактум по журналу выполнения «кто и когда согласовал» ломается уже через месяц. Сами записи запросов и ответов сохраняются в Dataverse13, но заглядывать в таблицу Dataverse каждый раз при аудите или обычном запросе непрактично, а поскольку история согласований расходует место в среде, её тоже могут удалить ради освобождения места.14

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

Есть один нюанс. Для типов с несколькими согласующими — «требуется согласование всех» или настраиваемые ответы (всех) — выходные данные Responses возвращаются массивом, по элементу на человека.3 Если последовательно перезаписывать этим единый набор столбцов, останется только последний ответ, поэтому для записи нескольких согласующих либо добавляйте по одной строке в отдельный список-журнал на каждый ответ, либо сначала форматируйте ответы всех участников в единый текст и уже потом записывайте его в столбец.

Тайм-ауты и напоминания — «согласование без срока» построить нельзя

Одно выполнение облачного потока длится не более 30 дней. В эти 30 дней входят и шаги в состоянии ожидания, например ожидающее согласование, и по истечении 30 дней такой шаг завершается по тайм-ауту.5 Если согласующий просто оставит запрос без ответа, поток тихо завершится ошибкой. Если начать эксплуатацию, не зная об этом, происходит худший с точки зрения доверия сбой: «подал заявку, и вообще ничего не произошло».

Меры принимаются в два этапа.

  1. Задайте явный тайм-аут для действия согласования. В настройках действия укажите тайм-аут в формате ISO 8601 (например, P3D для трёх дней) и подготовьте в разделе «Настройка выполнения после» (Configure run after) ветвь «в случае тайм-аута».15 Здесь важно то, что на момент срабатывания тайм-аута исходное ожидание согласования уже завершено. Даже если после этого согласующий всё-таки ответит, этот ответ уже не попадёт в последующие шаги данного выполнения (например, в запись результата). То есть ветвь тайм-аута — это не место, где «продолжаем ждать и попутно напоминаем», а место, где «обрываем текущее ожидание и предпринимаем следующий шаг». Если нужно напомнить, в ветви тайм-аута отправляют уведомление и затем выставляют новый запрос на согласование. Для схемы вроде «напомнить через 3 дня, эскалировать на 7-й день вышестоящему» проще и надёжнее всего выстроить последовательно 2-3 действия согласования с тайм-аутом (второй этап — повторный запрос с напоминанием, третий — адресован вышестоящему руководителю). Можно также обернуть цепочку «тайм-аут → напоминание → повторный запрос» в цикл Do Until, но у самого цикла Do Until есть отдельное ограничение (по умолчанию 60 итераций и 1 час), и если поместить внутрь длительное действие вроде ожидания согласования, второй и последующие витки не начнутся, пока вы явно не увеличите тайм-аут цикла через «Изменить ограничения».516
  2. Если согласование потенциально может занять больше 30 дней, разделите поток на два. Microsoft официально описывает конфигурацию, где действие «Создание согласования (v2)» только отправляет запрос, после чего первый поток завершается, а последующая обработка ответа выполняется отдельным потоком. Поскольку запись согласования хранится в Dataverse, ответ можно обработать даже после того, как выполнение исходного потока закончилось. Если хочется выстроить гибкие напоминания, не обрывая ожидание, такая конфигурация из двух потоков строится естественнее.17 Отметим, что способ запуска второго потока оставляет пространство для выбора: если строить его так, чтобы он напрямую подхватывал изменения таблицы согласований через триггер коннектора Dataverse, учтите, что коннектор Dataverse относится к премиум-лицензии (сами действия коннектора «Согласование» остаются в рамках стандартного тарифа1).18

Для согласования в небольшой или средней компании реалистичнее всего сначала утвердить внутреннее правило вроде «напомнить через 3 дня, эскалировать на руководителя через 7» и реализовать его либо циклом повторных запросов, либо конфигурацией из двух потоков.

Переназначение при отсутствии согласующего

Случаи длительного отсутствия согласующего неизбежны. Тот, кто получил запрос, может переназначить (Reassign) его на другого человека из списка согласований на портале Power Automate. Со стороны инициатора восстановление выполняется через отмену запроса, смену согласующего в потоке и повторный запуск.7 Важно отметить: в автоматически запускаемом потоке, как в этой статье, это становится задачей не заявителя, а владельца потока, — потому что запрос на согласование отправляется от аккаунта, использованного в подключении потока, а смена согласующего требует прав на редактирование потока. Вопрос «кто исправит поток, если согласующий уйдёт в отпуск по болезни» нужно решить заранее, вместе с темой совладельцев из следующей главы.

Однако переназначение предполагает, что «получивший запрос сам может это сделать», и не спасает при внезапном отпуске по болезни. Для постоянной подстраховки безопаснее не фиксировать согласующего как одного конкретного человека, а указать нескольких через точку с запятой в типе «первый ответ» или адресовать запрос группе.7 Поскольку у адресации группе есть ограничение — уведомление в Teams не отправляется8, — если важна гарантированная доставка уведомления, выбирайте указание нескольких имён.

Цикл возврата на доработку при отклонении

Цепочку «возврат на доработку → исправление → повторная подача», которую труднее всего было отследить в бумажном согласовании, легко выразить с помощью столбца статуса. Базовая схема такая.

  • Определить в настраиваемых ответах варианты «согласовать» и «вернуть на доработку»1
  • При возврате на доработку установить в столбце статуса списка значение «на доработке», записать в столбец комментарий согласующего и уведомить заявителя
  • Заявитель исправляет элемент списка и меняет статус на «повторная подача» (либо отправляет форму Forms заново)
  • Обновление элемента запускает поток заново, и заявка снова уходит на согласование

В этой схеме нужно учесть один момент: собственная запись потока может повторно его запустить. Если оставить триггер «при создании или изменении элемента» как есть, то в момент, когда поток обновляет столбец статуса на «ожидает согласования» или «согласовано», само это обновление удовлетворяет условию триггера — возникают повторные запросы на согласование или бесконечный цикл. Облачный поток способен запустить сам себя, и Power Automate при сохранении предупреждает о возможности бесконечного цикла.19 Решение — не отбрасывать такие случаи в условном ветвлении на позднем шаге, а прописать правило прямо в самом триггере через условия триггера (trigger conditions): «запускаться только когда столбец статуса равен ‘повторная подача’ (или элемент только что создан)». Обновление, не удовлетворяющее условию триггера, вообще не приводит к запуску потока, а значит, не расходует и счётчик выполнений.20

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

6. Эксплуатация и управление — поток не должен быть «собственностью того, кто его создал»

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

  • Настройте совладельцев. Владелец потока может смотреть журнал выполнения, редактировать и останавливать поток и даже обновлять учётные данные подключений. Если поток остаётся на одном создателе, он становится неисправимым в тот же момент, когда этот человек увольняется или переводится. Добавьте в совладельцы сотрудника ИТ-отдела или вероятного преемника. Есть также функция, позволяющая сделать совладельцем сам список SharePoint, уравняв «право редактировать список» с «правом редактировать поток»6, но если применить это к списку-приёму, в который пишут все заявители, как в данной статье, право на редактирование потока получат абсолютно все заявители. В процессах согласования эту функцию не используйте — ограничьте совладельцев конкретными сотрудниками, отвечающими за эксплуатацию, или административной группой.
  • Разберитесь, как устроены подключения. Подключение, которое использует поток (аутентификация к SharePoint или Outlook), привязано к создавшему его пользователю, а общий доступ к подключению работает только внутри данного потока. Кроме того, совладелец не может изменить учётные данные подключения, созданного другим владельцем.6 Именно отсюда берутся сбои вроде «письма с результатом согласования продолжают отправляться с аккаунта уволенного сотрудника» или «поток останавливается сразу после отключения аккаунта». То, какой аккаунт использовать для уведомлений и записи, нужно решить ещё до создания потока.

Отметим и то, что даже если потоком будут пользоваться другие отделы, делиться самим потоком с заявителями не нужно. В конфигурации из этой статьи поток запускается автоматически, если человек может просто ввести данные в приём (Forms или список SharePoint). Общий доступ следует ограничивать только теми, кто занимается редактированием и эксплуатацией, а совладельцев держать на необходимом минимуме — это общее правило.21

Более широкую тему управления Power Automate — лицензирование, разделение сред, политики DLP — мы разбираем в отдельной статье «Автоматизация бизнес-процессов с Power Automate — выбор между облачным потоком и потоком рабочего стола, проектирование обработки ошибок». Процесс согласования — тоже разновидность облачного потока, поэтому те же принципы применимы напрямую.

7. Где граница того, что стоит делать в Power Automate

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

Ситуация Оценка
1-3 ступени согласования, маршрут определяется простым условием (например, суммой) Power Automate вполне достаточно
Маршрут согласования динамически меняется по сочетанию оргструктуры, суммы и типа дела Ветвление обычно разрастается взрывообразно. Стоит рассмотреть систему документооборота или заказную разработку
Требуется делегирование полномочий, замещение должности или подстройка под реорганизацию Реализация только средствами Power Automate становится тяжёлой. Область специализированной системы
Требования аудита предполагают долгосрочное хранение следов согласования, защиту от подделки и исчерпывающий поиск Достаточно ли записи в SharePoint, зависит от требований; при строгих требованиях — система документооборота/СЭД
Обязательно воспроизвести макет заявки (вывод бланка с полем для печати) Нужен механизм генерации отчётов вне потока. Появляется элемент разработки

Интуитивный ориентир такой: если нарисовать ветвления потока на бумаге и они перестают умещаться на листе А4, значит, задача начинает выходить за рамки того, что покрывает Power Automate. Вместо того чтобы через силу наращивать поток, часто в итоге дешевле вынести саму логику определения маршрута согласования наружу (в таблицу Dataverse или отдельную систему) либо перейти на специализированную систему.

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

8. Итог

Настоящей проблемой бумажного и почтового согласования были не трудозатраты, а то, что «состояние не видно, записи разбросаны, возврат на доработку не отследить». Процесс согласования в Power Automate решает все три проблемы, собирая заявку и запись о согласовании в списке SharePoint и перенося сами действия согласования в Teams или Outlook. То, что зачастую это можно начать без дополнительных вложений в новые системы, — большое преимущество для компаний, уже внедривших Microsoft 365.

В то же время, если построить его, не зная об ограничениях в 28 дней журнала выполнения и 30 дней срока выполнения, получится процесс согласования, у которого «исчезает след» и «заявки тихо проваливаются». Запись результата, ветвление по тайм-ауту, несколько согласующих и совладельцы — заложите эти четыре пункта в проект с самого начала, и процесс согласования сможет надёжно работать долгое время. А момент, когда захочется реализовать «как есть» всю сложность регламента согласования, — это как раз сигнал присмотреться к специализированной системе или заказной разработке.

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

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

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

Справочные ссылки

  1. Microsoft Learn, Get started with approvals. О действии «Начать и дождаться согласования», пяти типах согласования (согласование всех/первый ответ/настраиваемые ответы/последовательное), о базе данных Dataverse как обязательном условии и о том, что коннектор «Согласование» — стандартный и доступен на лицензиях вроде Office 365. ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  2. Microsoft Learn, Respond to an approval from a chat or channel. О возможности ответить на запрос согласования из чата, канала или приложения «Согласование» в Teams. ↩ ↩2

  3. Microsoft Learn, Create an approval flow that requires everyone to approve. О конфигурации потока согласования, запускаемого созданием/обновлением элемента списка SharePoint, о доставке запросов по почте и через мобильное приложение Power Automate, а также о том, что при типе «согласование всех» отказ одного отклоняет всё целиком. ↩ ↩2 ↩3 ↩4

  4. Microsoft Learn, Missing runs or triggers history for a flow. О том, что журнал выполнения потока по умолчанию хранится только 28 дней. ↩ ↩2

  5. Microsoft Learn, Limits of automated, scheduled, and instant flows. О том, что срок выполнения облачного потока не превышает 30 дней и что ожидающий шаг, например согласование, тоже завершается по тайм-ауту через 30 дней. ↩ ↩2 ↩3

  6. Microsoft Learn, Share a cloud flow. О том, что может совладелец (просмотр журнала выполнения, редактирование потока, обновление учётных данных подключений, добавление владельцев), о том, что общее подключение работает только внутри данного потока, о невозможности изменить учётные данные подключения, созданного другим владельцем, и о возможности сделать совладельцем список SharePoint. ↩ ↩2 ↩3

  7. Microsoft Learn, How to - Top scenarios with approval flows. О переназначении (Reassign) получателем запроса, об отмене и смене согласующего инициатором, об указании нескольких согласующих через точку с запятой и об отображении письма согласования в Outlook. ↩ ↩2 ↩3

  8. Microsoft Learn, Request approvals from Microsoft 365 groups. О поведении согласования, адресованного группе, и о том, что уведомления в Teams отправляются только для согласований, адресованных отдельному пользователю, а не группе. ↩ ↩2

  9. Microsoft Learn, Approvals in Microsoft Teams. О создании запроса на согласование из приложения «Согласование» в Teams без создания потока и о том, что оно работает на платформе Power Automate. ↩ ↩2

  10. Microsoft Learn, Overview of flows with Microsoft Forms. О триггере Forms «при отправке нового ответа» и действии «получить сведения об ответе». ↩

  11. Microsoft Learn, Common ways to use a form in a flow. О шаблоне, подставляющем содержимое ответа Forms в запрос на согласование, и о переносе ответов в Excel или список. ↩

  12. Microsoft Learn, Manage cloud flow run history in Dataverse. О том, что для потоков, входящих в решение, журнал выполнения (FlowRun) хранится в Dataverse, срок хранения по умолчанию — 28 дней, и администратор может изменить его (TTL). ↩

  13. Microsoft Learn, Differences between flow approval actions. О том, что действия согласования создают запись в Dataverse, что «Начать и дождаться согласования» возвращает ответ, согласующего и комментарий как выходные данные, и о различиях между «Создание согласования» и «Ожидание согласования». ↩ ↩2

  14. Microsoft Learn, Free up storage space. О том, что история согласований потока расходует место в хранилище Dataverse и что удаление освобождает это место. ↩

  15. Microsoft Learn, Cloud flow error code reference. О явной настройке тайм-аута (формат ISO 8601) для действий согласования/ожидания, о ветви «в случае тайм-аута» в «Настройке выполнения после» и о работе с 30-дневным ограничением на срок выполнения. ↩

  16. Microsoft Learn, Limits and configuration reference for Azure Logic Apps. О том, что цикл Until по умолчанию ограничен 60 итерациями и тайм-аутом в 1 час (PT1H), что тайм-аут оценивается по каждому витку — превышение не останавливает уже выполняющийся виток, но не даёт начаться следующему, — и что значение можно изменить через «Изменить ограничения». Значение по умолчанию в 60 итераций для циклов облачного потока Power Automate также указано в Limits of automated, scheduled, and instant flows. ↩

  17. Microsoft Learn, Create and test an approval workflow with Power Automate. О использовании действия «Создание согласования (v2)» для согласований, которые могут превысить 30 дней, о разделении отправки запроса и обработки ответа на два потока и об отмене запроса на согласование. ↩

  18. Microsoft Learn, List of all Premium tier connectors. О том, что коннектор Microsoft Dataverse относится к коннекторам премиум-уровня. ↩

  19. Microsoft Learn, Avoid anti-patterns. О том, что облачный поток может запустить сам себя и уйти в бесконечный цикл, что при сохранении выводится предупреждение, и о способах избежать этого через условия триггера или действие Terminate. ↩

  20. Microsoft Learn, Customize your triggers with conditions. О том, что условие триггера не даёт запуститься выполнению для событий, которые ему не удовлетворяют, в отличие от отбрасывания случая в последующем условном ветвлении, которое всё равно расходует выполнение и запрос к API. ↩

  21. Microsoft Learn, Understand flow ownership and access. О том, что совладельцев следует добавлять только при необходимости, а общий доступ по умолчанию должен предоставляться только с правом запуска. ↩

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

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

Автоматическая обработка PDF-файлов заказов и счетов, приходящих по почте, в Power Automate — проектирование сохранения, распределения, уведомлений и распознавания

Разбираем проектирование автоматизации сохранения, распределения и уведомлений для PDF-файлов заказов и счетов, приходящих по почте, сред...

Читать статью

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

Разбираем различия между облачными потоками и потоками рабочего стола в Power Automate, выбор между PowerShell и VBA, лицензирование, обр...

Читать статью

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

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

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

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

Можно ли создать процесс согласования в Power Automate только на лицензии Microsoft 365?
Можно. Коннектор «Согласование» (Approvals) — стандартный, поэтому для создания процесса согласования достаточно любой лицензии, дающей доступ к стандартным коннекторам (например, Office 365). При этом для хранения данных согласования нужна база данных Microsoft Dataverse: в среде по умолчанию она автоматически создаётся при первом создании потока согласования. Комбинацию со списком SharePoint, Forms, Teams и Outlook тоже можно построить целиком в рамках стандартных коннекторов.
Что произойдёт, если согласующий оставит запрос без ответа?
Одно выполнение облачного потока длится не более 30 дней, и любой ожидающий шаг, в том числе ожидание согласования, по истечении 30 дней завершается по тайм-ауту. Поэтому «согласование без срока» построить нельзя. На практике для действия согласования задают явный тайм-аут и готовят в разделе «Настройка выполнения после» ветвь «в случае тайм-аута». После срабатывания тайм-аута исходное ожидание завершается, а последующий ответ уже не попадает в дальнейшие шаги, поэтому эту ветвь проектируют так, чтобы вместе с уведомлением-напоминанием сразу выставлялся новый запрос на согласование (с эскалацией вышестоящему руководителю по мере роста числа повторов). Если ждать нужно дольше 30 дней, работу разделяют на два потока: один с действием «Создание согласования (v2)», другой — для обработки ответа.
Где остаются записи о согласовании? Можно ли использовать их для аудита?
Запросы и ответы на согласование сохраняются как записи в Microsoft Dataverse, а сам журнал выполнения потока по умолчанию виден только 28 дней. Полагаться на журнал выполнения для аудита или последующих запросов рискованно. На практике я рекомендую в конце потока записывать результат согласования, согласующего, дату/время и комментарий в столбцы списка SharePoint, чтобы данные заявки и запись о согласовании можно было увидеть вместе, в одном месте.
Что делать, если согласующий отсутствует или уволился?
Тот, кто получил запрос на согласование, может переназначить (Reassign) его на другого человека из списка согласований Power Automate. Инициатор напрямую переназначить не может, но может отменить запрос, сменить согласующего в потоке и запустить его заново. Для защиты от постоянного отсутствия безопаснее не фиксировать согласующего как одного человека, а направлять запрос нескольким людям или группе — так поток реже застревает. Важно также с самого начала настроить совладельцев потока — на случай увольнения владельца самого потока.

Об авторе

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

Го Комура

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

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

Связаться с нами

Публичные ссылки

GitHub LinkedIn X COM_BLAS COM_BigDecimal
Вернуться в блог