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

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

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

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

• Основа утверждения в Power Automate — действие «Начать и ожидать утверждения». Тип выбирают из пяти вариантов: «нужно утверждение всех», «первый ответ», «настраиваемые ответы» (всех / одного) и «последовательное утверждение».¹
• Утверждающий может ответить из Teams, Outlook, портала Power Automate или мобильного приложения. Отдельный интерфейс «только ради утверждения» осваивать почти никому не нужно.²³
• Для приёма заявок реалистичны три варианта: Microsoft Forms, список SharePoint и приложение «Утверждения» в Teams. Если позже понадобятся сводный список и агрегация, обычно всё строят вокруг списка SharePoint.
• Журнал выполнения потока по умолчанию виден только 28 дней, а одно выполнение обрывается по тайм-ауту не позже чем через 30 дней. Не делайте журнал выполнения следом утверждения: с самого начала заложите запись результата, например в список SharePoint.⁴⁵
• Увольнение или перевод владельца потока — главный операционный риск потока утверждения. Совладельцев и работу с подключениями закройте в тот же день, когда поток пошёл в работу.⁶
• Если пытаться «как есть» реализовать многоступенчатое утверждение с обилием ветвлений, делегирование полномочий или жёсткий регламент по аудиту, сопровождать это в Power Automate уже не получится. Это область систем документооборота или заказной разработки.

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 21, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

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

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

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

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

3. Из чего собирается утверждение в Power Automate

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

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

Типов утверждения пять.¹

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

Чтобы пользоваться утверждением, нужна база Microsoft Dataverse. Записи запросов и ответов пишутся в Dataverse; в среде по умолчанию база появляется автоматически при первом создании потока утверждения, так что обычно об этом даже не думают. Коннектор утверждения — стандартный, поэтому поток можно собрать на любой лицензии со стандартными коннекторами (например, Office 365).¹

Что такое Dataverse — когда о нём всё-таки приходится помнить

Dataverse, который здесь появляется впервые, — общая платформа хранения данных Power Platform. Грубо говоря, это облачная база внутри вашего тенанта Microsoft 365: туда кладут данные приложений Power Apps и потоков. Утверждение сидит на этой базе: «кому и когда отправили запрос и кто как ответил» пишется строками в таблицы Dataverse.

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

• Когда утверждение впервые включают в новой среде. В среде по умолчанию база поднимается сама, а в среде, которую завели под подразделение, нужно проверить, есть ли база Dataverse.¹
• Когда история утверждений накопилась. Она занимает хранилище среды и при нехватке места может попасть под удаление. Отсюда же следует, почему след нельзя вешать ни на журнал выполнения, ни на Dataverse (следующая глава).⁷
• Когда хочется читать и писать записи утверждения напрямую. Если трогать таблицы коннектором Dataverse, этот коннектор относится к уровню Premium — появляется разговор про дополнительную лицензию.⁸

Граница такая: обычное утверждение — без доплаты за лицензию; как только начинаете трогать сам Dataverse, условия меняются.

Откуда утверждающий отвечает

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

Один нюанс. Если адресовать утверждение группе Microsoft 365, уведомление в Teams не уходит. В Teams оно приходит только для запросов конкретному человеку.¹⁰

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

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

flowchart TD
    Submit[Заявитель вводит данные<br/>отправка Forms / запись в список SharePoint] --> Trigger[Запуск облачного потока<br/>триггер нового ответа или добавления элемента]
    Trigger --> Record[Запись заявки в список SharePoint<br/>статус: ожидает утверждения]
    Record --> Approval[Начать и ожидать утверждения<br/>отправка запроса утверждающему]
    Approval -- Teams / Outlook / мобильное --> Response{Ответ}
    Response -- Утверждено --> UpdateOK[Обновить статус списка на «Утверждено»<br/>записать утверждающего, дату/время, комментарий в столбцы]
    Response -- Отклонено / на доработку --> UpdateNG[Обновить статус на «На доработке»<br/>уведомить заявителя о причине]
    Response -- Тайм-аут --> Remind[Напоминание / эскалация]
    UpdateOK --> NotifyOK[Уведомить заявителя о результате]
    UpdateNG --> Resubmit[Заявитель правит и подаёт повторно]
    Resubmit -- Условие триггера запускает<br/>только «повторную подачу» --> Trigger

Важный момент: шаг записи стоит и до, и после действия утверждения. Почему так — в главе 5.

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

Удобство потока утверждения задаёт не столько сторона утверждающего, сколько точка ввода на стороне заявителя. Реалистичных вариантов три.

Ориентир для выбора такой.

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

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

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

Куда писать историю утверждения — журнал выполнения для этого не годится

Это главное проектное решение. Журнал выполнения потока по умолчанию виден только 28 дней.⁴ Если поток входит в решение (solution), метаданные журнала можно хранить в Dataverse, но и там срок по умолчанию — 28 дней, а меняет его администратор.¹⁴

Иными словами, схема «потом посмотрим в журнале выполнения, кто и когда утвердил» разваливается уже через месяц. Сами записи запросов и ответов лежат в Dataverse¹⁵, но лазить в таблицу Dataverse при каждом аудите или обычном запросе нереально. К тому же история утверждений занимает хранилище среды и её могут удалить, чтобы освободить место.⁷

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

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

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

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

Меры — в два шага.

1. Задайте действию утверждения явный тайм-аут. В параметрах действия укажите длительность в ISO 8601 (например, P3D — три дня) и в «Настройке выполнения после» (Configure run after) подготовьте ветвь «если истекло время ожидания».¹⁶ Важно: к моменту тайм-аута исходное ожидание уже закончено. Даже если утверждающий ответит позже, этот ответ в следующие шаги данного запуска (запись результата и т. п.) не попадёт. Ветвь тайм-аута — не место «продолжать ждать и попутно напоминать», а место «оборвать ожидание и сделать следующий ход». Если нужно напомнить, в этой ветви отправляют уведомление и выставляют новый запрос на утверждение.
2. Если утверждение может занять больше 30 дней, разделите поток на два. Microsoft официально описывает схему, где действие «Создать утверждение (v2)» только отправляет запрос, первый поток на этом заканчивается, а дальнейшая обработка ответа идёт отдельным потоком. Запись утверждения лежит в Dataverse, поэтому ответ можно обработать даже после того, как исходный запуск уже завершился. Если хотите гибкие напоминания, не обрывая ожидание, два потока собираются прямее.¹⁷ Способ запуска второго потока можно выбрать по-разному: если он напрямую ловит изменения таблицы утверждений триггером коннектора Dataverse, учтите, что этот коннектор — Premium (сами действия коннектора утверждения остаются в стандартном тарифе¹).⁸

Как настроить тайм-аут и ветвление

По тексту это плохо ложится, поэтому выпишу щелчки в конструкторе по шагам.

1. В карточке «Начать и ожидать утверждения» откройте «…» справа сверху → Параметры (Settings) и в поле время ожидания (Timeout) введите длительность в ISO 8601. Три дня — P3D, двенадцать часов — PT12H. Если поле пустое, поток ждёт до предела длительности выполнения (30 дней).
2. Под действием утверждения поставьте одно действие, которое нужно при тайм-ауте (например, напоминание).
3. У этого действия откройте «…» → Настройка выполнения после (Configure run after) и для предыдущего действия утверждения отметьте только «Истекло время ожидания». По умолчанию стоит «Выполнено успешно» — его нужно снять, это часто забывают.
4. Обработку утверждения (запись результата, уведомление заявителя) поставьте другой ветвью от того же действия утверждения и оставьте ей «Выполнено успешно». Если ветвить через «Настройку выполнения после», в конструкторе две ветви рисуются параллельно.

Как сделать «через 3 дня напомнить, на 7-й день — вышестоящему»

Именно это обычно и хотят получить, поэтому покажу конкретную цепочку из двух–трёх ступеней. На первой ступени ждут 3 дня; нет ответа — напоминают и снова отправляют тому же руководителю; ещё через 4 дня уходит вышестоящему.

flowchart TD
    A1[Начать и ожидать утверждения, 1-я ступень<br/>утверждающий: непосредственный руководитель<br/>тайм-аут в параметрах P3D] --> Q1{Был ответ?}
    Q1 -- Утверждено / отклонено --> Rec[Записать результат в список SharePoint<br/>уведомить заявителя]
    Q1 -- 3 дня без ответа --> R1[Отправить напоминание<br/>Настройка выполнения после: истекло время ожидания]
    R1 --> A2[Начать и ожидать утверждения, 2-я ступень<br/>утверждающий: тот же руководитель<br/>тайм-аут в параметрах P4D]
    A2 --> Q2{Был ответ?}
    Q2 -- Утверждено / отклонено --> Rec
    Q2 -- ещё 4 дня без ответа --> R2[Отправить уведомление об эскалации<br/>Настройка выполнения после: истекло время ожидания]
    R2 --> A3[Начать и ожидать утверждения, 3-я ступень<br/>утверждающий: вышестоящий<br/>тайм-аут не задан]
    A3 --> Rec

При сборке важны три вещи.

• Вторая и третья ступени — это новые запросы на утверждение. Первый запрос через 3 дня уже закрыт, поэтому в Teams и Outlook утверждающего они приходят как отдельные запросы. В заголовок имеет смысл добавить «[Напоминание]» или «[Эскалация]», а в текст — дату заявки и сколько дней прошло: так получатель понимает, на чём остановились.
• Сумма тайм-аутов должна уместиться в 30 дней потока. В примере первая ступень 3 дня + вторая 4 дня = 7 дней, на третью остаётся чуть меньше 23 дней. Чем больше ступеней, тем меньше запас на последней.
• Если запись результата хотите держать в одном месте, заведите переменные. Результат утверждения на каждой ступени — выход другого действия, и если писать «как есть», шаг записи размножится на три места. В начале потока инициализируйте строковые переменные (например, РезультатУтверждения и Утверждающий), сразу после каждого действия утверждения ставьте «Задать переменную», а в список пишите один раз в конце — так потом проще сопровождать.

Цепочку «тайм-аут → напоминание → новый запрос» можно обернуть в цикл Do until, но у самого цикла свой предел (по умолчанию 60 итераций и 1 час). Если внутрь положить долгое действие вроде ожидания утверждения, вторая и следующие итерации не начнутся, пока явно не растянете тайм-аут цикла через «Изменить ограничения».⁵¹⁸ «Изменить ограничения (Change limits)» — ссылка внутри карточки Do until; в ней задаются число (Count) и время ожидания (Timeout). Число — сколько раз крутить (по умолчанию 60), время ожидания — лимит всего цикла в ISO 8601 (по умолчанию PT1H). Если трижды ждать утверждение по 3 дня, ставьте число 3 и время ожидания вроде P10D — «длиннее, чем сумма ожидаемых кругов». Растянуть это поле — не значит растянуть 30 дней всего потока.

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

Переназначение, когда утверждающего нет

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

Переназначение, однако, предполагает, что «получивший запрос сам может это сделать», и при внезапном больничном не спасает. На постоянную подстраховку безопаснее не закреплять одного человека, а перечислить нескольких через точку с запятой в типе „первый, кто ответит“ либо адресовать запрос группе.⁹ У группы ограничение: уведомление в Teams не уходит¹⁰, поэтому если важна доставка уведомления, берите перечисление нескольких имён.

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

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

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

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

Условия триггера задают так: в карточке триггера «…» справа сверху → Параметры (Settings) → условия триггера (Trigger Conditions), по одному выражению на строку, каждое с @ в начале. Чтобы список SharePoint с столбцом выбора ApprovalStatus запускал поток только при значении «повторная подача», пишут так.

@equals(triggerOutputs()?['body/ApprovalStatus/Value'], 'Повторная подача')

Чтобы запускаться и при создании (столбец статуса пуст), связывают через or.

@or(equals(triggerOutputs()?['body/ApprovalStatus/Value'], 'Повторная подача'), empty(triggerOutputs()?['body/ApprovalStatus/Value']))

В записи держат три правила.

• @ ставят только один раз, в начале. На вложенные equals и empty его не вешают.
• Для столбца выбора указывают путь до /Value. Такой столбец приходит объектом, не строкой: сравнение с body/ApprovalStatus не совпадёт. У столбца «одна строка текста» /Value не нужен.
• Во внутреннем имени столбца не используйте японские иероглифы. Если SharePoint получает японское имя столбца, внутреннее имя становится закодированной строкой вроде _x72b6__x614b_, и отображаемое имя в выражении не совпадёт. Столбцы, на которые ссылается поток, лучше завести с именем из латиницы и цифр, а уже потом сменить отображаемое имя на нужный язык — тогда такие выражения не съедают время. Внутреннее имя смотрят в URL страницы столбца в параметрах списка (после Field=).

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

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

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

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

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

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

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

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

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

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

8. Итог

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

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

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

• Автоматизация бизнес-процессов с Power Automate — выбор между облачным потоком и потоком рабочего стола, проектирование обработки ошибок
• Как перевести приём заказов по факсу в веб — проектирование периода двойной эксплуатации и практика поэтапного перехода
• Что такое EDI? Как упростить взаимные заказы между компаниями — от факса, почты и ручного ввода к обмену данными
• Что такое цифровой счёт-фактура? Чем это отличается от «отправки PDF счёта по почте»

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

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

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

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

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

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

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

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

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

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

Можно ли собрать поток утверждения в 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, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.