Тайм-аут согласований в Power Automate через 30 дней: эстафетный шаблон как решение

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

В этой статье объясняется, почему Power Automate завершает согласования примерно через 30 дней, что на практике происходит немного раньше, и как так называемый эстафетный шаблон из двух отдельных потоков позволяет аккуратно обрабатывать согласования с неопределённой продолжительностью. Актуально на июль 2026 года.

Почему Power Automate прерывает согласования через 30 дней

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

Это касается прежде всего действия Запустить и ожидать согласования, поскольку оно блокирует выполнение потока до получения ответа. Именно эта блокировка становится роковой, как только время ожидания достигает предела в 30 дней. К этому моменту поток технически уже не может продолжать работу, независимо от того, упустил ли согласующий запрос или просто ещё не успел его обработать.

Что на практике происходит уже через 28 дней

В обзоре известных проблем с согласованиями Microsoft указывает на особенность, которая на практике важнее, чем документированные 30 дней: процесс согласования, судя по всему, может ждать 28 дней, и если время ожидания превышает эти 28 дней, поток завершается со сбоем. Важно, что эта ошибка затрагивает только само выполнение потока. Согласование остаётся видимым в центре согласований, хотя ни один поток его больше не ожидает.

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

Эстафетный шаблон: два потока вместо одного долгого выполнения

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

Конкретно для этого используется действие Создать согласование (v2) вместо блокирующего действия Запустить и ожидать согласования:

• Поток A только отправляет: он создаёт запрос на согласование через Создать согласование (v2), записывает идентификатор согласования вместе с контекстом операции в таблицу Dataverse или другую исходную систему и сразу после этого завершается. Здесь не тикают часы 30-дневного ограничения, потому что поток не ждёт.
• Поток B берёт на себя логику: второй, независимый поток реагирует на ответ, например через триггер Dataverse при изменении статуса или через действие Ожидать согласования, связанное с ранее сохранённым идентификатором согласования. Он выполняет собственно бизнес-логику только тогда, когда решение действительно принято — будь то через три дня или через три месяца.

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

Подводный камень при разделении создания и ожидания

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

Особый случай: комплект согласований с автоматическим перезапуском после тайм-аута

Тот, кто вместо собственных потоков использует готовый комплект согласований, то есть приложение управления бизнес-согласованиями, уже получает часть этой защиты «из коробки». Согласно справочнику по статусам согласования там существует статус Ожидание (Тайм-аут): он означает, что согласующий не ответил в течение первых 30 дней и выполнение облачного потока Power Automate, управляющего этим запросом, автоматически перезапускается. После перезапуска статус снова возвращается к Ожидание, и запрос остаётся действительным.

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

Практические советы для устойчивых долгих согласований

• Закладывайте эстафетный шаблон с самого начала, как только согласование реалистично может оставаться открытым дольше трёх-четырёх недель, а не реагируйте лишь тогда, когда первый поток уже завершился со сбоем.
• Храните статус и идентификатор согласования вне потока, например в Dataverse или в списке SharePoint, чтобы второй поток мог подключиться в любой момент.
• Встройте напоминание, которое повторно отправляется согласующему примерно через 20 дней, чтобы решение принималось в практически пригодном временном окне.
• Регулярно очищайте осиротевшие согласования в центре действий, чтобы старые запросы не были случайно отвечены без того, чтобы какой-либо поток на это ещё реагировал.

Тот, кто не хочет выстраивать этот шаблон самостоятельно или должен обезопасить сразу несколько процессов согласования, может обратиться за сопровождением к специализированному поставщику услуг, такому как NordFlux. При этом вы сохраняете контроль над своим процессом, пока техническая защита от 30-дневного ограничения аккуратно работает в фоновом режиме.

Часто задаваемые вопросы

С какого именно момента прерывается согласование в Power Automate?

Официально документирована максимальная продолжительность выполнения в 30 дней на один запуск потока, но на практике, по данным Microsoft, поток может завершиться со сбоем уже через 28 дней, если время ожидания превышает это значение. При планировании стоит для надёжности ориентироваться на меньшее значение.

Что происходит с согласованием, которое остаётся в центре действий?

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

Достаточно ли эстафетного шаблона для неограниченно долгого времени ожидания?

Да, потому что ожидающий второй поток каждый раз выполняется лишь столько, сколько допускает одно действие ожидания, и при необходимости может запускаться заново, пока информация о согласовании централизованно хранится в Dataverse или другой исходной системе. При этом 30-дневное ограничение отдельного выполнения не отменяется, а становится несущественным для процесса в целом.

Распространяется ли автоматический перезапуск после тайм-аута и на самостоятельно созданные потоки?

Нет, автоматический перезапуск со статусом Ожидание (Тайм-аут) — это функция готового комплекта согласований с его собственной структурой Dataverse. Для индивидуально созданного потока согласования этот механизм придётся воспроизводить самостоятельно с помощью шаблона из двух потоков.

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

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