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

«Под конец месяца бухгалтерия рассылает по отделам письма: “срок сдачи авансовых отчётов — такое-то число”». «Каждое утро после начала рабочего дня кто-то открывает список заказов и глазами проверяет, не осталось ли необработанных». «Документы с истекшим сроком сверяют с реестром и по одному напоминают о просрочке». Даже в компаниях, где Microsoft 365 уже внедрён, такой работы — «человек смотрит в календарь и действует» — остаётся на удивление много. Забыть — значит получить сбой, а единственная страховка от забывчивости — память ответственного и его календарь Outlook.

Плановый запуск в Power Automate (триггер Recurrence) как раз автоматизирует такую регулярную работу. Но когда это пытаются собрать под японские бизнес-правила, сразу встают три стены: время по умолчанию — UTC (всемирное координированное время); понятия «рабочий день» во встроенных средствах нет; а «конец месяца» и «закрытие 20-го числа» нужно записывать выражениями. В статье разберём спецификацию и ловушки триггера Recurrence, набор выражений для дат, определение рабочего дня по справочнику праздников, как проектировать напоминания без лишнего шума и какие эксплуатационные риски характерны именно для плановых потоков.

Как в системах вообще обрабатывать японские требования к датам — японский календарь эпох, праздники и даты закрытия — подробно разобрано в отдельной статье «Японский календарь, праздники и даты закрытия в бизнес-приложениях — устойчивость к смене эры, JapaneseCalendar и расчёт рабочих дней». Эта статья — практическое применение той же логики к потокам Power Automate.

1. Главное сразу

• Время триггера Recurrence читается как UTC, если часовой пояс не указан. Чтобы «каждое утро в 9» не сработало в 18:00 по японскому времени, в поле пояса выберите «(UTC+09:00) Осака, Саппоро, Токио» и явно задайте время начала.¹²
• «Только по будням» собирается частотой «Неделя» и выбором дней (пн–пт). Но праздники при этом не учитываются. Фиксированную дату вроде «20-го числа каждого месяца» можно задать датой начала и частотой «Месяц», а переменную дату — «в последний день месяца», «в предыдущий рабочий день, если дата закрытия выпадает на выходной» — указать нельзя. Практический выход: запускать каждый день и проверять выражением.²
• utcNow() внутри выражений тоже всегда возвращает UTC. «Сегодня» по японскому времени получают через convertTimeZone(utcNow(), 'UTC', 'Tokyo Standard Time'). Если забыть про преобразование в потоке, который идёт около 8 утра, «сегодня» окажется вчерашним днём.³⁴
• Встроенного механизма определения японских праздников нет. В списке функций выражений праздничной функции тоже нет⁵, поэтому обычная схема — свой справочник праздников (например, список SharePoint) и в начале потока проверка, рабочий ли сегодня день: если нет — завершить выполнение. Первичным источником для справочника может быть CSV праздников Канцелярии Кабинета министров.⁶
• Напоминания собирают не «одно письмо на запись», а одно письмо на ответственного. Действия работы с данными вроде Filter array и Create HTML table позволяют собрать это читаемо, без вложенных Apply to each.⁷
• У планового потока трудно заметить, что он «не работает». Закладывайте уведомления о сбоях и журнал выполнения с первого дня, исходя из того, что поток отключается после 14 дней непрерывных сбоев, может отключиться после 90 дней без срабатывания триггера, а история выполнения по умолчанию хранится 28 дней.⁸⁹

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

2. Какие задачи «человек смотрит в календарь» стоит автоматизировать

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

Критериев три. Можно ли выразить условие данными («вроде бы подозрительная заявка» не автоматизируется), можно ли сформулировать словами правило дня запуска и можно ли на следующий день восстановиться после сбоя (если нельзя — это область разработки из главы 8).

Из трёх второй в японской практике самый трудный. Даже фраза «напоминание о закрытии в конце каждого месяца» на деле означает, что человек двигает дату: «если конец месяца выпадает на выходной или праздник — перенести на предыдущий рабочий день, а в год с Golden Week отправить до длинных выходных». Считайте, что перевод этого неявного знания в спецификацию и есть основная работа по созданию потока. Если оставить это размытым и просто собрать поток, доверие потеряете так: «напоминание о просрочке ушло в праздник» или «напоминание перед длинными выходными пришло уже во время них».

3. Триггер Recurrence: основы и ловушки

Плановый облачный поток создают как «Запланированный облачный поток» (Scheduled cloud flow), а частоту и интервал задают триггером Recurrence (повторение).¹ Частоту выбирают из секунд, минут, часов, дней, недель и месяцев; минимальный интервал — 60 секунд, максимальный — 500 дней.⁸ Сама спецификация проста, но ловушек у этого триггера много.

Сначала общая картина. Строки идут в том порядке, в каком на них чаще наступают во внутренних японских потоках (пункт 6 актуален только если в контуре есть зарубежный офис).

Ловушка 1. По умолчанию UTC — «должно быть в 9, сработало в 18»

Это самая частая авария. Если часовой пояс не выбран, время начала триггера Recurrence читается как UTC с суффиксом Z (YYYY-MM-DDThh:mm:ssZ). Если в поле пояса выбрать Японию, время начала читается как локальное время этого пояса (YYYY-MM-DDThh:mm:ss, без Z).¹² Для потока «уведомлять каждое утро в 9» правильная настройка — пояс «(UTC+09:00) Осака, Саппоро, Токио» и время начала 9:00.

Ловушка 2. Без времени начала поток срабатывает сразу при сохранении

Если дату и время начала не указать, первое выполнение стартует в момент сохранения потока.² На тесте это терпимо, но поток с рассылкой напоминаний, сохранённый вечером, может тут же разослать письма всем. Дату и время начала указывайте всегда.

Кроме того, если в дополнительных параметрах не задать «время выполнения» (these hours / these minutes), каждый следующий запуск считается относительно предыдущего, и накопленные задержки постепенно сдвигают (дрейфуют) фактическое время.² Для потока, который должен идти в один и тот же час каждый день, безопаснее явно указать и час запуска вместе с датой начала.

Ловушка 3. «Только по будням» можно, детальная настройка месяца — ограниченно

При частоте «Неделя» можно выбрать дни недели (пн–пт), при частоте «День» или «Неделя» — ещё и час запуска (часы, минуты). То есть «только в 9 утра по будням» собирается одними настройками триггера. Эти подробности доступны только для частот «День» и «Неделя»: у частоты «Месяц» нет поля вроде «20-е число каждого месяца» или «последний день месяца».²

Если же дата фиксированная и месячная, гонять поток каждый день не нужно. Поставьте дату начала на нужный день (например, 20-е число следующего месяца, 9:00) и частоту «Месяц»: выполнение пойдёт раз в месяц от этой точки, так что «9:00 20-го числа каждого месяца» собирается только настройками триггера.² Не стоит каждый день запускать поток (365 раз за год), которому достаточно 12 срабатываний в месяц, и отбрасывать лишние запуски проверкой: история выполнения становится нечитаемой, а лимит запросов тратится впустую.

Конструкция «запускать каждый день и в начале потока выражением проверять, сегодня ли нужная дата» нужна для месячной работы с переменной датой. «Последний день месяца» (от 28 до 31 в зависимости от месяца), «предыдущий рабочий день, если 20-е выпадает на выходной или праздник», «N-й рабочий день каждого месяца» триггером не выразить. Это выражение разберём в следующей главе. Фиксированная дата начала на 29–31 число ещё требует отдельно проверить поведение в месяцах, где такого дня нет, поэтому обработку около конца месяца безопаснее сразу строить как «ежедневный запуск + проверка».

Ловушка 4. Выражение в триггере фиксируется в момент сохранения

Если во вход триггера записать выражение вроде utcNow(), значение вычисляется и фиксируется в момент сохранения потока. При каждом запуске оно заново не пересчитывается.¹⁰ Идея «впишу выражение в триггер, чтобы время начала стало сегодняшним» не работает — это стоит запомнить. Даты считают не в триггере, а действиями внутри потока (глава 4).

Ловушка 5. Пропущенные за время отключения запуски задним числом не выполняются

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

Ловушка 6. Летнее время — только если есть зарубежный офис

Если задать время в UTC, не выбирая пояс, в регионах с летним временем (DST) при каждом переходе час запуска сдвигается на час. Если пояс выбран, расписание само следует за сезоном.¹¹ В Японии летнего времени нет, поэтому для чисто внутренних процессов вреда нет. Но если тот же поток шлёт уведомления зарубежному офису, для него нужно явно выбрать пояс этого офиса.

4. Набор выражений для дат — конец месяца, начало месяца, дата закрытия

Даты внутри потока считают теми же выражениями (функциями), что и в Logic Apps.⁵ Исходная точка: utcNow() всегда возвращает текущее время в UTC.¹² Поэтому схема, при которой в самом начале потока получают «сегодня по японскому времени», кладут в переменную (или Compose) и дальше только её переиспользуют, делает выражения заметно читаемее.

convertTimeZone(utcNow(), 'UTC', 'Tokyo Standard Time', 'yyyy-MM-dd')

convertTimeZone(метка_времени, исходный_пояс, целевой_пояс, формат) — функция преобразования часового пояса¹³, а имя пояса берётся из списка часовых поясов Windows. Для Японии это «Tokyo Standard Time».⁴ Если писать выражение не хочется, то же самое делает действие «Преобразование часового пояса» (Convert time zone).¹³

Преобразование обязательно, потому что между UTC и японским временем девять часов. До 9 утра по японскому времени в UTC всё ещё предыдущий день. Если в потоке, который идёт в 8 утра, написать formatDateTime(utcNow(), 'yyyy-MM-dd'), в качестве «сегодня» вернётся вчерашняя дата. Расхождение то появляется, то нет — зависит от часа запуска, поэтому на тесте его легко не заметить, а в продакшене оно всплывает так: «обработка начала месяца сработала ещё и в последний день предыдущего».

Куда писать это выражение — переменная, Compose и вкладка «Выражение»

На старте работы с Power Automate здесь обычно путаются, поэтому зафиксируем сразу.

• Инициализация переменной (Initialize variable): действие в группе «Переменные» при «Добавить действие». Задаёте имя, тип (строка и т. д.) и значение, дальше ссылаетесь как variables('today'). Сюда кладут то, что меняется внутри цикла или что позже перезапишут действием «Задать переменную».
• Создание (Compose): ищете compose при «Добавить действие» — действие в группе «Операции с данными». Оно просто держит результат выражения из поля «Входные данные». Это способ не писать одно и то же несколько раз⁷, поэтому «сегодня по японскому времени» — значение, которое считают один раз и больше не меняют, — сюда подходит лучше. Ссылка идёт по имени действия, например outputs('Today').
• Где писать само выражение: в обоих действиях щелчок по полю значения открывает панель динамического содержимого и выражений. Вставьте convertTimeZone(...) на вкладке «Выражение» (значок fx) и подтвердите. Внешний вид зависит от версии конструктора, но порядок один: сначала поле ввода, затем вкладка выражений.
• Имена действий и переменных подставляются в выражения, поэтому безопаснее латиница и цифры (пробелы в имени заменяются на подчёркивание).

Дальше в статье «сегодня по японскому времени», полученное этим выражением, обозначается как Сегодня. В реальном потоке подставьте variables('today') или outputs('Today'). Ниже — типичные проверки после того, как Сегодня уже есть.

addDays, addToTime, startOfMonth, formatDateTime, dayOfWeek определены в общем справочнике выражений Logic Apps и Power Automate.⁵ Комбинированные выражения из таблицы — авторский шаблон реализации, поэтому перед продакшеном прогоните их на датах, которые пересекают конец и начало месяца и високосный год (29 февраля). Насколько опасны ошибки дат, которые всплывают только в конкретный день, и как выбирать даты для предварительного теста, разобрано в главе 4 статьи «Японский календарь, праздники и даты закрытия в бизнес-приложениях».

5. Определение рабочего дня — праздники хранят в справочнике

Встроенной проверки праздников нет

Повторим: в Power Automate нет встроенной функции, которая определяла бы японские праздники. Выбор дня недели в триггере Recurrence буквально смотрит только на день недели, а в списке функций выражений есть сложение и вычитание дат, форматирование и преобразование пояса — функции «это праздник?» там нет.⁵ Почему праздник принципиально нельзя вычислить формулой (дни весеннего и осеннего равноденствия утверждают только в предыдущем году, а сами праздники двигаются из-за поправок закона и специальных законов), подробно написано в главе 3 статьи «Японский календарь, праздники и даты закрытия в бизнес-приложениях». Вывод тот же: правильный путь — хранить праздники как данные (справочник) и поддерживать их обновлением.

В Power Automate проще всего завести список SharePoint «Справочник праздников» (столбец даты + столбец названия). Первичным источником подойдёт CSV дат и названий праздников с 1955 года (昭和30) по следующий год, который публикует Канцелярия Кабинета министров (перенесённые выходные входят туда же отдельными строками).⁶ Публикуют только уже утверждённые данные, поэтому проектирование включает и то, что раз в год загрузку дат следующего года в справочник нужно поставить в производственный календарь. Если обновление забыть, сбой будет прямым: напоминание уйдёт в праздник следующего года. Корпоративные нерабочие дни вроде летних каникул или дня основания компании в справочник праздников не смешивайте — заведите отдельный список. Набор нерабочих дней, на который нужно смотреть, зависит от задачи: «для срока банковского перевода смотрим только праздники», «для внутренних напоминаний смотрим ещё и корпоративные выходные».

Guard рабочего дня в начале потока

Для потока, который должен идти только в рабочие дни, к выбору дней недели в Recurrence (пн–пт) в начале потока добавляют такую проверку.

1. Получить «сегодня по японскому времени» (глава 4)
2. Выполнить действие SharePoint «Получить элементы» (Get items) по справочнику праздников и найти сегодняшнюю дату фильтром вида HolidayDate eq 'Сегодня'¹⁴
3. Точно так же поискать в списке корпоративных выходных
4. Если найдена хотя бы одна запись, остановить выполнение действием «Завершить» (Terminate)

Terminate немедленно останавливает поток и завершает его в указанном состоянии (успех / сбой / отмена); внутрь Apply to each или Do until его поставить нельзя.¹⁵ Если здесь задать состояние «Отменено» (Cancelled), в истории выполнения с первого взгляда будет видно «день, пропущенный как нерабочий» и «день, когда обработка реально шла». Это сильно упрощает разбор по сравнению с тем, если все запуски помечены как «успешные».

Перенос на предыдущий рабочий день и «за N рабочих дней»

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

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

flowchart TD
    Start[Пройден guard рабочего дня<br/>сегодня точно рабочий] --> Hol[Собрать праздники этого месяца<br/>Get items по справочнику праздников и корпоративным выходным]
    Hol --> Days[Посчитать оставшиеся дни<br/>день конца месяца минус сегодняшний день]
    Days --> Zero{Оставшихся дней 0?}
    Zero -- да --> Run[Сегодня последний рабочий день<br/>закрытие месяца и напоминания]
    Zero -- нет --> Range[Массив дат с завтра до конца месяца<br/>range и addDays]
    Range --> Filter[Filter array: убрать сб/вс и праздники]
    Filter --> Len{Осталось 0 дат?}
    Len -- 0 --> Run
    Len -- 1 и более --> Skip[Terminate, Отменено<br/>сегодня не день переноса]

Конкретно это выглядит так.

1. Собрать праздники этого месяца. Get items забирает из справочника праздников и списка корпоративных выходных только записи текущего месяца, действие «Выбор» (Select) сводит их к массиву строк yyyy-MM-dd, union() склеивает в один список.¹⁴⁵ Имя этого действия — Holidays.

2. Получить дату конца месяца и число оставшихся дней. Берутся выражения из главы 4.

   КонецМесяца: addDays(startOfMonth(addToTime(Сегодня, 1, 'Month')), -1, 'yyyy-MM-dd')
   ОстатокДней: sub(int(formatDateTime(КонецМесяца, 'dd')), int(formatDateTime(Сегодня, 'dd')))
   

3. Если оставшихся дней 0, сегодня — конец месяца. Guard рабочего дня уже пройден, значит сегодня последний рабочий день. Идём в обработку.
4. Если оставшихся дней 1 и больше, собрать массив дат с завтра до конца месяца. В действии «Выбор» (Select) в начало ставят range(1, ОстатокДней), в сопоставление — addDays(Сегодня, item(), 'yyyy-MM-dd'). Второй аргумент range() обязан быть положительным целым⁵, поэтому ветку шага 3 нужно ставить раньше обязательно: без неё поток упадёт ошибкой только в сам день конца месяца.

5. Убрать субботы, воскресенья и праздники. Выход шага 4 передают в «Фильтрация массива» (Filter array), условие переключают в расширенный режим и пишут такое выражение.⁷ createArray(0, 6) — номера воскресенья и субботы¹², body('Holidays') — список праздников из шага 1.

   @and(not(contains(createArray(0, 6), dayOfWeek(item()))),
        not(contains(body('Holidays'), item())))
   

6. Решение по числу оставшихся дат. Если действие шага 5 названо Filter array, к его выходу обращаются как body('Filter_array') (пробел в имени становится подчёркиванием). Если length(body('Filter_array')) равен 0, «после сегодня рабочих дней нет» = сегодня последний рабочий день месяца, и обработку выполняют; если 1 и больше — сегодня не день переноса, поток завершают Terminate в состоянии «Отменено».⁵¹⁵

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

N рабочих дней до срока, например «напомнить за 3 рабочих дня до даты оплаты», — то же переформулирование. «Наступило N рабочих дней до срока» заменяют на «запускать каждый рабочий день, считать рабочие дни от сегодня до срока и сравнивать с N». Счёт рабочих дней — это просто счёт дней, которые «не сб/вс, нет в справочнике праздников, нет в списке корпоративных выходных». Но обработка, в которой поток перебирает даты по одному дню в цикле, при сотнях записей превращается в цикл «число записей × число дней» и раздувает и время выполнения, и число вызовов API. На таком масштабе расчёт рабочих дней лучше вынести из потока (таблица рабочих дней в базе или небольшой API) либо отнести к области разработки из главы 8.

6. Напоминания и просрочка — одно письмо на ответственного

Предпосылка: реестр должен быть данными

Напоминания о просрочке можно автоматизировать только если «что, за кем и до какого срока» уже доступно как данные. Если реестр до сих пор живёт Excel-файлом в общей папке и ходит вложением по почте, сначала имеет смысл перенести его в список SharePoint (это разобрано в статье «Как заменить Excel-реестр списком SharePoint»). Дальше предполагается, что в списке SharePoint уже есть столбцы «Срок», «Состояние» и «Ответственный».

Отбирать при получении, а не после

Просроченные записи отбирают не так, что сначала забирают весь список, а условие проверяют внутри потока, — фильтруют на сервере OData-фильтром действия Get items.¹⁴

DueDate lt '2026-07-18' and Status ne 'Выполнено'

В часть с датой подставляется выражение «сегодня по японскому времени» из главы 4. Учтите: в фильтре нужны внутренние имена столбцов SharePoint, а не подписи на экране; по умолчанию возвращается не больше 100 записей, поэтому для больших списков задают лимит (Top Count) или включают пагинацию.¹⁴

Как не утонуть в Apply to each — одно письмо на человека

Если просто прогнать выборку через Apply to each и слать письмо на каждую запись, у сотрудника A при 10 необработанных каждое утро будет 10 писем. Так несколько недель — и уведомления перестанут читать, механизм напоминаний умрёт. Принцип: уведомления сводят в одно письмо на каждого ответственного. Действиями работы с данными это собирается так.⁷

1. Select строит из выборки массив адресов ответственных, union() убирает дубликаты — получается «список ответственных, которых нужно уведомить сегодня»⁵
2. Список ответственных прогоняют через Apply to each, внутри Filter array оставляет «только записи этого человека»
3. Create HTML table оформляет тему, срок и состояние в таблицу, её вставляют в тело письма (или сообщения Teams) и отправляют одно сообщение (для почты включают отображение HTML⁷)

Общая схема такая.

flowchart TD
    Rec[Триггер Recurrence<br/>будни, 9:00, пояс: Осака, Саппоро, Токио] --> Today[Сегодня по японскому времени<br/>convertTimeZone]
    Today --> Hol{Сегодня есть в справочнике праздников<br/>или корпоративных выходных?}
    Hol -- есть --> Term[Terminate, Отменено<br/>не рабочий день, выход]
    Hol -- нет --> Get[Get items<br/>просрочено и не завершено]
    Get --> Any{Есть записи?}
    Any -- нет --> End([Выход без уведомления])
    Any -- да --> Sel[Select: список ответственных<br/>union убирает дубли]
    Sel --> Each[Цикл по ответственным]
    Each --> Filter[Filter array<br/>только записи этого человека]
    Filter --> Table[Create HTML table: оформить таблицу]
    Table --> Send[Одно уведомление ответственному<br/>Teams или Outlook]
    Send --> Log[Записать результат в список-журнал]

Когда Teams, когда Outlook

Канал выбирают по характеру сообщения.

Типовая схема: ежедневные сводки — в Teams, официальные напоминания перед датой закрытия и письма о просрочке — по почте. Гнать одно и то же в оба канала не стоит: растёт только общий объём уведомлений.

Как не слать слишком часто

Самый опасный сбой автоматизации напоминаний — разослать столько, что всё начнут игнорировать. У живого человека есть естественный тормоз: «неловко напоминать слишком часто». У потока его нет. Тормоз закладывают в проект.

• Спроектировать объём. Худший вариант — каждое утро, всем, по всем записям. Сужайте условия: ежедневно слать только по сегодняшнему сроку и уже просроченному, предварительные напоминания — два раза, за 3 рабочих дня и накануне.
• Ввести ступени. Сначала только самому ответственному; если просрочка держится N рабочих дней — добавить руководителя. Если слать руководителю всё с первого дня, уведомления становятся шумом.
• Оставить способ остановить. Обязательный выход: ответственный ставит столбец состояния в списке в «Выполнено» — со следующего дня письма прекращаются. Если отчёт о выполнении так и остаётся ответом на письмо, поток продолжает слать напоминания, а человек начинает ненавидеть сам поток.
• Держать состояние, в котором «нет письма = нет проблемы». Это работает только вместе с мониторингом из следующей главы.

7. Эксплуатация — плановый поток «не даёт заметить, что остановился»

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

• Поток может отключиться сам. Поток, у которого триггер или действия продолжают завершаться ошибкой, отключается через 14 дней; поток, который постоянно упирается в throttling, тоже через 14 дней. Кроме того, поток, который ни разу не сработал за 90 дней, может быть отключён (это не касается потоков, чей владелец имеет премиум-лицензию или лицензию на ёмкость, например Process; за 30 дней до отключения владельцу и совладельцам приходит уведомление, и включив поток снова, можно продолжить).⁸ Если вы делаете «поток раз в квартал», правило 90 дней нужно учитывать.
• История выполнения по умолчанию видна только 28 дней.⁹ Для ежемесячного потока это значит, что проверить можно по сути только последний запуск. Если в конце потока добавить шаг, который пишет одну строку «дата и время запуска, число обработанных записей, результат» в список-журнал SharePoint, вопрос «действительно ли поток отработал в прошлом месяце» можно проверить независимо от срока хранения истории. Именно поэтому запись в журнал стоит последним шагом на схеме главы 6.
• Дайте самому потоку способ сообщить о сбое. Без ветки, которая уведомляет администратора при сбое (действие с условием выполнения «в случае сбоя»), 14 дней до автоотключения никто ничего не заметит. Как собирать обработку ошибок и повторы, подробно разобрано в статье «Обработка ошибок и повторные попытки в Power Automate».
• Уход или перевод владельца останавливает всё расписание. Поток с триггером Recurrence выполняется через подключение создателя потока.¹⁰ Если учётная запись владельца отключена, подключение обрывается, поток начинает сбоить и в итоге отключается. Совладельцев и разбор подключений нужно закрыть в первый день эксплуатации.¹⁶ Как передавать дела, собрано в статье «Как не привязать Power Automate к одному человеку — чтобы поток не остановился, когда автор уйдёт».
• Пропущенные за время отключения запуски не выполняются позже (ловушка 5 из главы 3). Выключая поток ради доработки или устранения сбоя, смотрите ближайшую запланированную дату и заранее решайте, как догнать пропуск ручным запуском, если период отключения её перешагнул.¹¹

8. Где граница Power Automate

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

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

9. Итоги

Проектирование планового потока сидит не столько в настройке триггера Recurrence, сколько до и после него. До — спецификация неявного знания «действовать по календарю»: что делать, если конец месяца выпадает на выходной, кто и когда заносит праздники в справочник. Поток, собранный без этих решений, обязательно сломается о японский календарь. После — эксплуатация, которая позволяет заметить остановку: 28 дней истории выполнения, условия автоотключения, расписание, которое встаёт из-за ухода владельца. Закладывайте уведомления о сбоях и журнал выполнения с первого дня, исходя из того, что плановый поток останавливается молча.

Технически достаточно трёх пунктов: явно указывать часовой пояс (по умолчанию UTC), дату перед проверкой переводить в японское время, праздники держать в справочнике и отсекать нерабочие дни guard-проверкой в начале потока. Освоив эти три, сводите уведомления по ответственным и давайте напоминаниям ступени и выход. Тогда значительную часть работы «человек смотрит в календарь и действует» можно заменить плановым потоком, которому можно доверять. А момент, когда захочется войти в «зафиксировать» — закрытие периода или пакетные задания корпоративной системы, — как раз время думать о переходе в разработку.

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

• Автоматизация бизнес-процессов в Power Automate — облачный поток и поток на компьютере, проектирование обработки ошибок
• Японский календарь, праздники и даты закрытия в бизнес-приложениях — устойчивость к смене эры, JapaneseCalendar и расчёт рабочих дней
• Обработка ошибок и повторные попытки в Power Automate
• Как не привязать Power Automate к одному человеку — чтобы поток не остановился, когда автор уйдёт
• Когда брать Power Automate, а когда PowerShell и Планировщик заданий

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

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

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

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

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

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

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

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

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

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

Как в Power Automate запускать плановый поток каждое утро в 9:00 по японскому времени?

В поле часового пояса триггера Recurrence выберите «(UTC+09:00) Осака, Саппоро, Токио» и укажите время начала. Если пояс не задан, время начала читается как UTC (всемирное координированное время) с суффиксом Z, поэтому «9:00» на деле сработает в 18:00 по японскому времени. utcNow() в выражениях тоже всегда возвращает UTC: когда внутри потока нужна «сегодняшняя дата», сначала переведите её в японское время, например convertTimeZone(utcNow(), 'UTC', 'Tokyo Standard Time', 'yyyy-MM-dd').

Есть ли в Power Automate функция, которая определяет японские праздники?

Встроенной нет. В триггере Recurrence можно выбрать дни недели и запускать поток «только по будням», но праздники при этом не учитываются, и среди функций выражений тоже нет ни одной, которая возвращала бы праздник. На практике заводят свой справочник дат праздников (например, список SharePoint) и в начале потока проверяют, есть ли сегодняшняя дата в справочнике: если день не рабочий — завершают выполнение. Первичным источником для обновления справочника может быть CSV праздников, который публикует Канцелярия Кабинета министров Японии (内閣府).

Можно ли сделать поток, который выполняется только в последний рабочий день месяца?

Для фиксированной даты вроде «20-го числа каждого месяца» достаточно поставить дату начала на нужный день и частоту «Месяц»: тогда запуск будет каждый месяц в тот же день и час, отсчитываясь от даты начала. Прямой опции «в последний день месяца» у триггера Recurrence нет, а дни недели и точное время можно задать только при частоте «День» или «Неделя». Для переменной даты, как конец месяца, поток запускают каждый день (или каждый будний день) и в начале выражениями проверяют, сегодня ли конец месяца и рабочий ли это день; в остальные дни выполнение завершают. Конец месяца записывается так: «если месяц сегодня и месяц завтра различаются, сегодня — последний день месяца». Правило «если конец месяца выпадает на выходной или праздник, выполнить в предыдущий рабочий день» получают, добавив к той же схеме проверку по справочнику праздников.

Плановый поток отключился сам, без моего ведома. Почему?

В Power Automate есть несколько условий автоматического отключения. Поток, у которого триггер или действия продолжают завершаться ошибкой, отключается через 14 дней; поток, который постоянно упирается в throttling (превышение лимитов), тоже через 14 дней. Кроме того, поток, который ни разу не сработал за 90 дней, может быть отключён (это не касается потоков, чей владелец имеет премиум-лицензию или лицензию на ёмкость; за 30 дней до отключения владельцу и совладельцам приходит уведомление). Остановку планового потока трудно заметить, поэтому уведомления о сбоях и журнал выполнения нужно закладывать с первого дня.

Об авторе

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

Го Комура

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

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