Power Platform Questions I See Every Week (And Their Real Answers)

These are questions I see repeatedly — in community forums, in Teams channels, in code reviews. Some have straightforward answers. Some have answers that require understanding a bit of how the platform works underneath.

---

”Why is my Power Automate flow only processing 5000 items?”

This is the most common Dataverse-related question in Power Automate.

When you use the List rows action from the Dataverse connector, the default page size is 5000 rows and the action doesn’t automatically paginate. If your table has 6000 records, you get 5000 and the rest are silently dropped.

The fix:

Enable pagination in the action settings. Click the three dots on the List rows action → Settings → turn on Pagination → set a threshold.

Be careful: setting pagination to a very high number (like 100,000) and processing rows one by one in a For each loop will hit the 100,000 action run limit on most license tiers. For large datasets, use a batch approach — process in pages of 1000 using the $skiptoken from @odata.nextLink.

For very large datasets (100k+ rows), consider a different approach entirely: export to Azure Data Lake, use a dataflow, or call a custom API that does the bulk processing outside of Power Automate.

---

”My canvas app formula works for 500 records but breaks at 5000”

This is a delegation problem.

Power Apps formulas like Filter(), Search(), SortByColumns(), and others can either run server-side (delegated to the data source) or client-side (pulled to the device, then processed). When a formula is non-delegable, Power Apps fetches a limited number of records (default 500, max 2000) and filters them locally. Records beyond that limit don’t exist as far as your formula is concerned.

What’s delegable depends on the data source. For Dataverse, Filter() on most indexed columns is delegable. StartsWith() is delegable. Search() is not fully delegable. Complex nested conditions may not be.

The yellow triangle in Power Apps Studio on a formula means it’s non-delegable. Don’t ignore it.

Solutions:

• Rewrite the formula using delegable functions where possible
• Use a View in Dataverse with server-side filtering instead of filtering in the app
• Use Search() only on the already-filtered result set, not the full table
• For unavoidably large datasets, use a custom API that returns pre-filtered data

---

”Why does my Dataverse flow trigger fire twice?”

This is almost always caused by a system update triggering your flow.

When your flow updates a row in Dataverse, that update itself triggers any flows listening for row changes on that table — including the flow that just ran. You end up with a loop, or at minimum double-firing.

Solutions:

1. Add a condition column. Add a xyz_ProcessedByFlow yes/no column. Check it at the start of the flow; skip if already true. Set it to true before your update logic.

2. Filter the trigger. In the Dataverse “When a row is added, modified or deleted” trigger, use the Filter rows (OData filter) to only trigger when relevant columns change, not all changes.

3. Check who triggered the change. triggerOutputs()?['body/_modifiedby_value'] gives you the user ID that made the change. If it matches your flow’s service account, skip processing.

4. Use a different trigger. If you’re triggering on update, consider whether you actually need a flow at all — a Business Rule or Plugin might be more appropriate for row-level validation logic.

---

”My Power Automate flow HTTP action returns 401 — how do I authenticate?”

Depends on what you’re calling.

Calling Dataverse Web API directly: Use the Managed Identity of the flow if it’s in the same tenant, or a Service Principal (app registration) with a Dataverse application user. Get a token from Azure AD:

POST https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token

client_id={app_id}
client_secret={secret}
scope=https://{your-env}.crm.dynamics.com/.default
grant_type=client_credentials

Then use the token in your HTTP action: Authorization: Bearer {token}

Calling an Azure Function: Enable Easy Auth on the Function App (Azure AD authentication) and configure the flow to call it using a managed identity or OAuth. Alternatively, use a function key for simpler scenarios.

Calling a third-party API: It depends on the API. OAuth APIs need a proper OAuth flow — use the custom connector framework with the OAuth 2.0 authentication type, not a raw HTTP action, if you need token refresh.

---

”How do I pass data between branches in a Parallel Branch?”

You can’t — at least not directly. This is a common architectural mistake.

Parallel branches run simultaneously. There’s no guaranteed order of completion, and they can’t write to and read from the same variable reliably.

The correct pattern: initialize all variables before the parallel branches. Each branch reads from the shared input (trigger data, previously set variables) and writes to its own output. After the parallel branches, collect results.

If Branch A’s output is needed by Branch B, they shouldn’t be parallel. Make them sequential.

---

”My model-driven app is slow — where do I start?”

Performance problems in model-driven apps usually fall into a few categories:

1. Form with too many subgrids. Each subgrid is a separate query. A form with 6 subgrids fires 6+ queries on load. Consolidate subgrids, use tabs so non-primary subgrids load lazily, or use Quick View Forms instead of full subgrids where possible.

2. JavaScript running on form load. If OnLoad runs synchronous JavaScript that calls the API, it blocks the form render. Move API calls to async functions and don’t block the form load.

3. Unindexed columns in views. If your view filters or sorts on a column without a Dataverse index, performance degrades as data volume grows. Check your view filters and add indexes to frequently filtered columns in the table definition.

4. Business rules with complex conditions. Business rules with many conditions and cross-field logic run on every field change. Profile which rules are firing and simplify where possible.

5. Too many security roles. The security model evaluation is expensive when users have many overlapping roles. Simplify role assignments where possible.

Use the Performance Center in model-driven apps (press Ctrl + Shift + Q) to see a breakdown of what’s taking time on form load. Start with what’s actually slow, not what you assume is slow.

---

”Can I call Power Automate from a Canvas App without a Premium license?”

The short answer: if you’re calling a flow that uses Premium connectors (Dataverse, HTTP, etc.), users of the canvas app need a Premium license.

The specific rule: the user running the app needs a license that covers all connectors used by flows triggered from that app. If the flow uses only standard connectors, a Microsoft 365 license is sufficient. If it touches Dataverse or any Premium connector, a Power Apps per-user or per-app license is required.

The pattern that sometimes gets misused: some teams try to call an Azure Function from the canvas app via HTTP, and have the Azure Function call Dataverse — thinking this avoids the Premium requirement. It doesn’t. The HTTP connector in Power Automate is Premium. And using Azure Functions as a workaround for licensing is against Microsoft’s licensing terms.

If you need Dataverse and want to manage costs, the per-app plan is more affordable than per-user for limited-use cases. Check the official licensing guide for current pricing.