Dataverse Service Protection Limits – Why 6,000 Requests Is Only Part of the Story

If you've worked with Dataverse integrations long enough, you've probably encountered this number: 6,000 requests in five minutes. It often gets repeated as: "The Dataverse API limit is 6,000." But after the previous articles in this series, we should already know why that statement needs more context. Dataverse doesn't have one simple API limit. The … Continue reading Dataverse Service Protection Limits – Why 6,000 Requests Is Only Part of the Story →

The Shared Service Account Problem

"All our Power Automate connections use the same service account." I've seen this architecture many times. At first, it sounds sensible. Instead of connections belonging to individual developers, create something like: svc-powerplatform@contoso.com Use that account for Dataverse connections. Build connection references around it. Then your flows aren't dependent on Bob, Sarah or John remaining with … Continue reading The Shared Service Account Problem →

Tenant Pooling: Whose Requests Are They Anyway?

We saw that a licensed user can have an individual request entitlement, while a Process-licensed flow can have its own dedicated entitlement. But Microsoft documentation introduces another concept: Pooled non-licensed tenant-level requests. The word pool is where things can become confusing. If an organisation has hundreds of licensed users, it is tempting to imagine all … Continue reading Tenant Pooling: Whose Requests Are They Anyway? →

Power Platform Request Allocations – Who Gets What?

In the previous article, we looked at what actually counts as a Power Platform Request. That naturally leads to the next question: How many requests do I actually get? This is where things start getting interesting. You might have heard numbers such as: 6,000. 40,000. 250,000. 500,000. And depending on the conversation, every one of … Continue reading Power Platform Request Allocations – Who Gets What? →

Who Actually Pays for the Request?

Understanding Flow Owners, Connections, Service Accounts, and Application Users The Four People Behind Every Flow Imagine a warehouse. Power Platform works the same way. Identity 1 - The Triggering User This is the person or system that starts the journey. Examples: A user updates a Case. A customer submits a form. An email arrives. A … Continue reading Who Actually Pays for the Request? →

The Journey of a Single Request

Opening Hook Imagine a customer raises a support ticket. "Our Power Automate flow is suddenly slow." As developers, our instinct is usually to open the flow designer. Sometimes one of those fixes works. Most of the time... We are fixing the wrong thing. Because we don't actually understand what happens after a flow is triggered. … Continue reading The Journey of a Single Request →

There Is No Such Thing as “The Power Platform API Limit”

Every few months I see another discussion where someone says: "Dataverse API limit is 6000." "No, it's 40,000 requests." "Actually it's 250,000." "Power Automate allows 500,000." Everyone sounds correct. Yet everyone is talking about a completely different limit. That is exactly why Power Platform limits are so confusing. Microsoft hasn't created one limit. They have … Continue reading There Is No Such Thing as “The Power Platform API Limit” →

Why This Record Appears First: Understanding Relevance Ranking, Facets, and Filters in Dataverse Search

In the previous article, we explored how Dataverse prepares searchable information behind the scenes so users can search across multiple tables almost instantly. But another question naturally follows: When several records match my search, why does one appear at the top while another appears further down the list? The answer lies in relevance ranking, along … Continue reading Why This Record Appears First: Understanding Relevance Ranking, Facets, and Filters in Dataverse Search →

Power Automate Data Operations What They Actually Do and When to Use Each One

There is a quiet tax on most Power Automate flows: unnecessary loops. You retrieve 500 items from SharePoint. You need 12 of them. So you loop through all 500, checking a condition on each one, building a new array one item at a time. The flow works. It's also doing 488 units of work it … Continue reading Power Automate Data Operations What They Actually Do and When to Use Each One →

Stop Copying Logic Across Flows. Use Child Flows

Here's a scenario that plays out on almost every Power Platform project. You have three approval workflows: one for project proposals, one for leave requests, one for expense submissions. Each one needs to look up the list of approvers from a SharePoint group. So you build that lookup logic into the first flow, then copy … Continue reading Stop Copying Logic Across Flows. Use Child Flows →