Power Automate: limity požadavků a chyba 429

Tok se během importu zpomalí a konektor vrátí chybu 429. Správce vidí v jedné tabulce 40 000 požadavků, v druhé 200 000 a v provozních statistikách jen osm tisíc. Nákup další licence může být správné řešení pro chybějící denní kapacitu. Nevyřeší však automaticky krátkou špičku proti konkrétnímu API.

Rozlišujte nárok na Power Platform requests, přechodné vynucování limitů a technickou ochranu služby. Stejné slovo „limit“ zde neznamená stejné měřidlo, časové okno ani způsob nápravy. Z úspěšného běhu nad oficiálním nárokem také neodvozujte, že se návrh do licencované kapacity vejde trvale.

Obsah ověřen k 21. říjnu 2026. Text se soustředí na cloud flows v Power Automate a jejich volání do Dataverse či konektorů. Agent flows mají jiné měření; samotné spouštění desktop flow podle aktuální dokumentace Power Platform requests nespotřebovává. Příklady níže jsou vlastní výpočty, nikoli naměřený výkon tenantu.

Jeden běh toku není jeden požadavek

Přehled requests a jejich přídělů zahrnuje v Power Automate API volání konektorů, HTTP akce i vestavěné akce typu inicializace proměnné nebo Compose. Počítají se úspěšné i neúspěšné akce, opakování a další požadavky při stránkování. Dvacet položek ve smyčce může provést stejný krok dvacetkrát. Započítejte také trigger a samotné řídicí akce: jeden trigger a jedna provedená akce podle FAQ představují dvě započítané akce, nikoli jednu.

Rozpočet proto nezačínejte počtem spuštění. Určete počet skutečně provedených započítávaných akcí v jedné cestě, počet průchodů smyčkou, aktivní větve a opakování. Krok, který v dané větvi vůbec neproběhl, neposuzujte stejně jako tisíckrát provedenou akci uvnitř smyčky. Návrh ověřte proti historii běhů, nikoli jen počtu bloků na plátně.

Microsoft také uvádí, že volání Power Automate do Dataverse se při tomto posouzení nepočítá automaticky dvakrát jen proto, že použije dvě služby. To neznamená, že každá složitá integrace má jednu jedinou operaci; další skutečně vyvolané kroky a relevantní operace je nutné zohlednit podle jejich vlastních pravidel.

Tři vrstvy limitů

V limitech cloud flows se objevují i výkonnostní profily a provozní hodnoty. Nepřekládejte je přímo do smluvního nároku konkrétního uživatele. Nejdřív určete, zda čtete tabulku přídělů, přechodného vynucování, nebo limit cílového konektoru.

Další nezávislou hranicí je v dokumentaci Power Automate limit 100 000 požadavků za pět minut, nezávislý na uživatelské licenci. Nezaměňujte jej s mnohem nižším výchozím limitem počtu Dataverse API požadavků ve stejně dlouhém okně. Jsou to různé vrstvy stejného toku.

Proč jsou u Premium současně čísla 40 000 a 200 000

Aktuální dokumentace přídělů výslovně uvádí přechodné období pro všechny organizace. U Premium a zahrnutých uživatelských nároků se během něj uplatňuje limit na jednotlivé cloud flow; cílový model pracuje s uživatelským nárokem. Process a původní per-flow plány zůstávají kapacitou toku i po přechodu. Pro návrh používejte oficiální nárok, ne pouze benevolentnější aktuálně pozorovaný strop.

Tabulka neříká, že uživatel Premium vlastní 40 000 plus 200 000 dohromady. Hodnoty popisují jiné úrovně a fáze vynucování. Microsoft uvádí, že oficiální vynucování nezačne dříve než šest měsíců po obecné dostupnosti usage reportingu. Dokud není potvrzen konkrétní milník a návazné datum, nepřidávejte do projektu vlastní odhad konce přechodu.

Zahrnuté Power Platform možnosti některých Microsoft 365 plánů mají v oficiální tabulce 6 000 požadavků za 24 hodin, nikoli automaticky Premium nárok. Samotné označení Microsoft 365 E5 proto neřadí tok do libovolně vysokého profilu Power Automate. Přesná práva používat konektory a kapacita jsou související, ale odlišné kontroly.

Kterému účtu spotřebu přiřadit

Licenční FAQ Power Automate rozlišuje automatické a plánované toky od ručních. U automatických a plánovaných typicky rozhodují limity vlastníka; u ručních například vyvolávající uživatel. Účet uložený v connection nemusí být identita, podle které určíte celý nárok toku.

U jedné licencované osoby nesčítejte nároky za každé prostředí znovu. Dvě prostředí neznamenají dva nové příděly stejné licence. Současně nelze volné požadavky jiného zaměstnance bez dalšího přesunout do společného uživatelského poolu. Rozlišujte více příslušných licencí stejné osoby a kapacitu různých osob.

Samostatnou kategorií je tenantový pool nelicencovaných identit, například application users. Každý nově vytvořený service principal nedostane nový vlastní tenantový pool. Dokumentace navíc uvádí případy, kdy service-principal flow čerpá Process, příslušnou flow group nebo limity designated licensed user místo tohoto poolu. Změna typu vlastníka tedy vyžaduje přepočet, nikoli pouze odstranění hesla servisního účtu.

Vlastní výpočet ukáže problém dřív než incident

Hypotetický model: jeden uživatel Premium vlastní plánované importy ve dvou prostředích. Předpokládáme, že použité akce se započítávají a nejde o Process flow ani zvláštní jiný kapacitní model. Jeden import má 1 200 záznamů, čtyři započítávané akce na záznam a dalších 200 započítávaných akcí mimo opakované čtyři kroky, včetně triggeru a řízení smyčky.

Oficiální nárok 40 000 je překročen o 5 500, přestože každý jednotlivý import má jen 5 000 a současné přechodné limity mohou běh dovolit. Přehled pouze prvního prostředí by ukázal 31 500 a problém skryl. Retry a stránkování přičítáme jen proto, že v modelu nejsou součástí původních čtyř akcí a fixní části; v reálném reportu je nesmíte přičíst podruhé k již zahrnuté spotřebě.

Pro cloud flows dokumentace popisuje klouzavé 24hodinové okno. Dávka těsně před půlnocí a další hned po půlnoci proto nevytvářejí automaticky dvě nezávislé denní kapacity. Denní export je vhodný pro trend, ale sám neprokazuje průběh libovolného klouzavého okna.

Chyba 429 může přijít hluboko pod denním limitem

Dataverse service protection sleduje počet požadavků, souhrnný čas zpracování a souběh. Dokumentace uvádí výchozí hodnoty na webový server: 6 000 požadavků za pět minut, 1 200 sekund souhrnného zpracování ve stejném okně a souběh 52 nebo vyšší podle prostředí. Limity se mohou mezi prostředími lišit; nejde o univerzální garantovaný výkon každého tenantu.

Výpočet času je souhrnný. Několik souběžných drahých požadavků proto může vyčerpat 1 200 sekund práce v pěti minutách skutečného času. Zvýšení paralelismu nepřidává bezplatný výkon; může přesunout problém od počtu volání k času nebo souběhu.

Příklad: stejný volající odešle 7 000 Dataverse požadavků během čtyř minut na jeden webový server s uvedeným výchozím limitem. Denní spotřeba může být stále pod 40 000, ale pětiminutový limit počtu volání tím není splněn. Čas nebo souběh mohou tok omezit i dříve. Je to vysvětlení mechanismu za daných předpokladů, ne slib, že každý tenant vrátí stejnou chybu u stejného pořadového volání.

U Dataverse respektujte odpověď Retry-After a podle ní opakování. Neřešte přetížení okamžitou smyčkou neomezených retry. U jiného konektoru ověřte jeho vlastní dokumentaci a návratovou chybu; ne každé API používá shodná pravidla. Snižujte nepřiměřené dávky, rozložte zpracování a zajistěte, aby bezpečně opakovaná operace nevytvářela duplicitní obchodní záznamy.

Report není úplný obraz celé Power Platform

Aktuální návod v přehledu přídělů a reportingu vede v Power Platform admin center přes Licensing, Capacity add-ons a Download reports k reportům Microsoft Power Platform requests. Rozlišuje Licensed User, Non-licensed User a Per Flow Licensed Flows. Konkrétní navigace se může s portálem měnit; důležitý je také zvolený typ reportu.

Dokumentace označuje tyto downloadable reporty jako preview a omezuje je na Power Automate API requests. Nezahrnují v této podobě všechny API požadavky Power Apps, Dataverse a Copilot Studio. Chybějící spotřeba tedy nemusí znamenat nulovou aktivitu služby.

U Licensed User reportu jsou popsány další dvě chyby čtení: příděl se může ukázat po uživateli, dni a prostředí, ale nesmí se násobit počtem prostředí. U Power Apps per app a odpovídajícího PAYG může být nárok chybně uveden jako nula místo příslušných 6 000. Nulu v takovém poli proto nepovažujte automaticky za důkaz chybějící licence.

Kdy přidat kapacitu a kdy změnit provoz

Pokud je problém skutečně v celkovém nároku, posuďte odpovídající vyšší pokrytí uživatele nebo Process kapacitu pro konkrétní tok. Aktuální dokumentace uvádí pro Process 250 000 PPR a možnost přímého navýšení na jednom solution-aware flow. Flow group má jiná pravidla sdílení a stackování; podrobnosti řeší Premium, Process a servisní účty.

Requests add-on s popisovaným přírůstkem 50 000 není v současném stavu jednoduché tlačítko pro přiřazení jednomu throttlovanému flow: přehled výslovně uvádí, že jej nyní nelze přiřazovat uživatelům nebo tokům. Nevystavujte proto objednávku pouze na základě názvu doplňku bez kontroly, jak bude potřebná kapacita skutečně přidělená.

Pokud je příčinou omezení konektoru či service protection, začněte rychlostí, souběhem, typem operací a řízeným opakováním. Vyšší denní entitlement nezruší pravidla cílového API. U Dataverse současně nezaměňujte request kapacitu za databázové, souborové a log úložiště; jejich měření vysvětluje Dataverse: proč nesedí volná kapacita.

Postup při zpomalení nebo chybě

1. Uložte čas, flow a run ID, konkrétní akci, odpověď konektoru a případný Retry-After.
2. Určete, zda se hlásí request entitlement, Power Automate provozní limit, konektor, nebo Dataverse service protection.
3. Ověřte typ toku, skutečného vlastníka či vyvolávajícího a použitý kapacitní model.
4. Sečtěte relevantní spotřebu včetně dalších toků a prostředí stejného uživatele; nárok téže licence nenásobte.
5. Rozlište celkovou spotřebu od krátké špičky a počítejte s klouzavým oknem.
6. Zvolte cílenou nápravu: kapacitu, omezení zbytečných akcí, rozložení dávek či řízený souběh.
7. Ověřte dokončený obchodní výsledek, nikoli jen zelený retry. Po opravě porovnejte také duplicity a nezpracované položky.