What it does

Every licensed user gets a daily allowance of Power Platform requests, and for Power Apps that means all API calls to connectors and to Dataverse. It's a licensing construct with a throttling mechanism behind it — separate from, and on top of, the per-service protection limits that actually fire on most projects.

Key facts

• For Power Apps, a request is all API requests to connectors and to Dataverse. For Dataverse specifically that's every create, read, update, delete, assign and share — including calls made internally by plug-ins, classic workflows and custom controls.
• Daily allowances per licence, over a rolling 24 hours: 40,000 for paid Power Platform users and most Dynamics 365 Enterprise and Professional licences; 6,000 for Power Apps per app, the pay-as-you-go plan, Microsoft 365 licences with Power Platform access, and Dynamics 365 Team Member; 200 for a paid Power Pages login.
• Multiple licences stack. A user with both a D365 Customer Service Enterprise base licence and a Power Apps per user licence has 80,000.
• In the Dynamics 365 base + attach model, only the base licence carries request limits. Attach licences add none.
• Non-licensed identities — application users, non-interactive users, administrative users and SYSTEM — draw from a separate tenant-level pool. Power Apps contributes 25,000 base requests with no per-licence accrual. A tenant with D365 Enterprise or Professional licences gets 500,000 base plus 5,000 per USL up to 10,000,000, and the larger pool wins if both apply.
• Limits don't roll over, don't accumulate, and the tenant pool is shared across all non-licensed identities rather than being per-identity.
• Dataverse excludes a small set of internal system operations — login, logout, system metadata — and platform-internal requests such as sdkmessagerequest, solutioncomponentdefinition and ribbonclientmetadatareporting.
• The Power Platform Request capacity add-on raises a limit by 50,000 per 24 hours and can be stacked. Microsoft currently notes these can't be assigned to users during the transition period, while still recommending you buy them to stay within licence terms.

When to use / skip

There's nothing to configure, so the useful question is whether these limits are a real risk on your project. For a typical app estate — a few thousand users doing normal transactional work — they aren't, and Microsoft says as much: limits were raised substantially in late 2021 to sit well above typical usage. Where they become a genuine design constraint is integration-heavy work: a service principal doing bulk sync, a plug-in that fans out CRUD operations, an app with a screen that fires dozens of Dataverse calls on load. Those hit the non-licensed tenant pool, which for a Power-Apps-only tenant is a fairly modest 25,000 a day and has no accrual.

Configuration decisions

• Whether integration work runs under an application user (tenant pool, no accrual for Power Apps) or a licensed user identity, and whether the pool can carry it.
• Whether the app's data access patterns are designed against request counts at all — caching into collections, filtering server-side, avoiding repeated fetches of the same source.
• Whether the client buys request capacity add-ons proactively to stay inside licence terms, or waits for enforcement.
• Whether pay-as-you-go is linked as an overage route for environments doing heavy work.
• Which identity owns background processes, since an automated or scheduled process always uses the owner's limits regardless of who triggered it.

Gotchas

• Enforcement isn't strict today. Microsoft is explicit: high-usage enforcement won't begin until at least six months after Power Platform request usage reporting reaches general availability, and there's no ETA for that GA. What you get today is documented limits with soft enforcement — but designing against the transition-period generosity is building on sand.
• The preview usage reports in the admin centre are limited to Power Automate API requests. Dataverse, Copilot Studio and Power Apps requests aren't included. So the reporting that's meant to tell you whether apps are near their limits doesn't cover apps.
• The licensed user report shows entitlement as 0 for users licensed via per app or the per app pay-as-you-go meter. It should show 6,000. Known limitation, not a licence problem.
• Daily request limits are not the same thing as service protection limits. The 429s you actually see in Live monitor are almost always Dataverse service protection limits or connector-specific limits, which are separate documents and separate behaviour.
• Swapping Power Automate for a third-party integration tool to dodge limits doesn't work — Microsoft states non-Microsoft tools are subject to the same limits.
• A flow called from an app doesn't double-count against Dataverse, but the flow's own actions count against whoever owns it.

Consultant notes

• Don't lead with these numbers in a design workshop. They frighten clients into over-engineering, and the limit that will actually bite them is service protection throttling on a badly written screen.
• Do raise them for any integration or migration workstream running under a service principal. That's the scenario where the tenant pool is genuinely small relative to the work.
• If a client asks whether they're compliant, be straight: the reporting to answer that doesn't cover Power Apps yet, so the honest answer is an estimate from Live monitor and design review, not a report.
• Put the enforcement timing in the risk log rather than the assumptions. "Not currently enforced" is a state that will change, and the six-month notice period is the client's planning window, not yours.

---

Sticky note: this changes the day Power Platform request reporting goes GA — recheck whether Power Apps requests are covered and whether the enforcement clock has started.