Power Automate: ограничение в 100 МБ и chunking как обходное решение (FAQ)

Power Automate ограничивает каждое отдельное сообщение в облачном flow до 100 МБ, и это ограничение обычно даёт о себе знать в самый неподходящий момент: посреди отправки видео по электронной почте, при загрузке резервной копии в SharePoint или при обработке большой коллекции PDF-файлов. Согласно официальной документации Power Automate по ограничениям размер сообщения для одного исходящего или входящего HTTP-запроса по умолчанию составляет 100 МБ, а при включённом chunking это значение можно увеличить до 1 ГБ. Актуально на: июль 2026 года.

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

Что именно Power Automate ограничивает до 100 МБ?

Согласно Microsoft, ограничение в 100 МБ применяется к размеру сообщения одного исходящего или входящего HTTP-запроса в облачном flow, то есть ко всему телу сообщения, которое обрабатывает действие или триггер. Важно: ограничение относится не исключительно к самому файлу, а ко всей полезной нагрузке запроса. Если вы отправляете файл через коннектор, согласно документации вся полезная нагрузка, включая метаданные, информацию заголовков и возможную обёртку JSON, должна оставаться ниже 100 МБ, а не только чистый размер файла. Файл размером 98 МБ может, таким образом, уже дать сбой, если вместе с ним пересылаются дополнительные данные.

Почему ограничение достигается уже при заметно меньшем файле?

Частая проблема при работе с действиями SharePoint и OneDrive, такими как «Получить содержимое файла», заключается в кодировании. Двоичное содержимое внутри flow часто передаётся в виде строки Base64, и такое кодирование увеличивает объём данных примерно на треть по сравнению с исходным размером файла. Файл размером 70 МБ может таким образом фактически вырасти примерно до 90–95 МБ ещё до того, как достигнет собственно целевого действия, и достигает ограничения в 100 МБ заметно раньше, чем можно было бы предположить по исходному размеру файла. Тем, кто регулярно работает с файлами в диапазоне от 60 до 90 МБ, стоит поэтому ожидать проблем задолго до отметки ровно в 100 МБ.

Как работает chunking как официальное обходное решение?

Chunking разбивает большое сообщение на более мелкие части, которые передаются одна за другой и вновь собираются в месте назначения. Power Automate при этом опирается на механизм chunking из Azure Logic Apps, как описывает документация по обработке больших сообщений: действие сначала отправляет пустой POST- или PUT-запрос с заголовками `x-ms-transfer-mode: chunked` и `x-ms-content-length`, целевая конечная точка отвечает предложенным размером блока через `x-ms-chunk-size`, а затем следует несколько HTTP PATCH-запросов, каждый из которых передаёт определённый диапазон байтов файла, пока всё содержимое не поступит в место назначения. Для загрузки больших объёмов содержимого этот процесс работает зеркально, через HTTP GET-запросы с заголовками `Range` и ответами с кодом состояния 206.

Включение chunking в HTTP-действии

На практике обычно достаточно одного клика: откройте HTTP-действие в конструкторе flow, перейдите в настройки и включите в разделе «Передача содержимого» опцию «Разрешить chunking». После этого Power Automate автоматически берёт разбиение на себя, если целевая конечная точка поддерживает тот же протокол chunking. Важный побочный эффект: если chunking активен для действия, в выходных данных остаются доступны только чистые данные содержимого, такие свойства, как код состояния или заголовки, пропадают. Если вы ссылаетесь на эти значения в другом месте flow, например в отслеживаемых свойствах, это приводит к ошибке во время выполнения, которую следует устранить заранее.

Где сам chunking упирается в собственные границы?

• Chunking работает исключительно для действий, но не для триггеров. Триггер вроде «Когда файл создан или изменён» по-прежнему остаётся привязанным к меньшим ограничениям, независимо от настроек chunking в остальной части flow.
• Даже при включённом chunking жёсткий верхний предел составляет 1 ГБ на сообщение. Для файлов большего размера одного этого механизма уже недостаточно.
• Не каждый коннектор и не каждый внешний API поддерживает протокол chunking Power Automate. Собственные веб-сервисы должны реализовать тот же протокол, иначе разбиение не даёт эффекта и запрос продолжает завершаться сбоем.
• Внутри flow по-прежнему учитывается общая пропускная способность по содержимому: в зависимости от профиля производительности предусмотрено дополнительно лишь от 200 МБ до 10 ГБ общего объёма данных в день по всем запускам.

Какая альтернатива существует для файлов больше 1 ГБ?

Для действительно больших файлов, например экспортов видео или объёмных резервных копий баз данных, даже включённый chunking рано или поздно перестаёт помогать, поскольку жёсткий предел в 1 ГБ на сообщение по-прежнему действует. В этом случае имеет смысл обходной путь через HTTP-действие, которое напрямую обращается к Microsoft Graph API и запускает там так называемую upload session для соответствующей папки. Файл при этом загружается на стороне сервера блоками, при этом всё содержимое никогда не проходит через flow как единое сообщение. Вы при этом сохраняете контроль над процессом, поскольку сами управляете размером блока и логикой повторных попыток внутри flow, вместо того чтобы полагаться на единственную рискованную попытку загрузки. Там, где такое решение должно быть аккуратно настроено и оставаться поддерживаемым в долгосрочной перспективе, NordFlux помогает с технической реализацией в рамках своего консалтинга по Power Automate.

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

Действует ли ограничение в 100 МБ для каждого действия в Power Automate?

Да, в принципе для каждого отдельного исходящего или входящего HTTP-запроса внутри облачного flow, независимо от того, идёт ли речь о стандартном коннекторе или о собственном HTTP-действии. Отдельные коннекторы могут дополнительно иметь собственные, часто более низкие ограничения, которые срабатывают ещё до общего ограничения в 100 МБ.

Что конкретно меняется при включении chunking?

Соответствующее действие автоматически разбивает большие сообщения на более мелкие блоки и передаёт их одно за другим, благодаря чему используемое ограничение увеличивается со 100 МБ до 1 ГБ. Взамен в выходных данных действия остаются доступны только чистые данные содержимого, а другие выходные свойства, такие как код состояния или заголовки, пропадают.

Работает ли chunking также с триггером вроде «Когда файл создан»?

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

Как понять, что я упёрся в ограничение?

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

Что делать с файлами, которые превышают 1 ГБ даже при chunking?

В этом случае стандартного решения из flow уже недостаточно. Имеет смысл использовать HTTP-действие, которое запускает upload session через Microsoft Graph API и загружает файл на стороне сервера блоками, либо аналогичный обходной путь через другой сервис хранения, который обрабатывает большие файлы напрямую, не пропуская их полностью через flow.