Insights & ideas

TL;DR

IT teams often face a recurring challenge: when should you build on Power Platform and when should you use Dynamics 365? Power Apps feel cheaper, faster, and more flexible, but without clear guardrails you risk rebuilding D365 from scratch, hitting licensing roadblocks, or paying twice for overlapping features. D365 and Power Platform share the same foundation but differ in cost models, out-of-the-box functionality, and roadmap alignment. The takeaway is not to choose one over the other, but to make intentional, use-case-driven decisions: use Dynamics 365 when you need depth, integration, and proven processes; use Power Platform when speed, flexibility, and cost control matter; and often combine both in a hybrid setup. The key is governance — aligning licensing and platform choice with real business needs instead of reacting case by case.

Are you rebuilding what you already own?

"We keep building custom Power Apps for everything — approvals, asset tracking, even sales processes. But are we just rebuilding Dynamics 365 from scratch?"

‍

Many IT Ops teams are stuck in a familiar loop: defaulting to custom Power Platform solutions because they’re faster, more flexible, or just feel cheaper. But somewhere along the way, you start to wonder: when does it actually make sense to use the out-of-the-box Dynamics 365 apps instead?

This is the third part of our series on D365 licensing. In our previous article, we discussed

• the basics of Dynamics 365 licensing and access management

• and how to right-size your D365 license setup using the CRUD framework

This post isn’t here to give you a magic answer (spoiler: there isn’t one). Instead, we’ll help kickstart the conversation with a few practical pointers, especially around licensing, and give you the clarity to make better decisions for your business and your budget.

When Power Platform feels like the obvious choice

Power Platform is gaining serious momentum. Go to any community event or conference and you’ll notice the shift: more sessions, more partners, more real-world stories. In many ways, Dynamics 365 tools are built on the same Dataverse platform. They share storage, governance, security, and admin tools. The main differences are their licensing and their out-of-the-box feature-set.  

So it’s no surprise many teams ask:

“Why pay £71.60/month for Sales Enterprise when I can build a tailored Power App for £4.10 per user or £16.40 per app?”

“Do we really need the full first-party app — or just a few of the features?”

“Why lock ourselves into Microsoft’s roadmap when we can create what we need ourselves?”  

They’re good questions. But they don’t always lead to the right outcome.

The challenge? You’re making decisions without the full picture

The core issue isn’t D365 vs. Power Platform. It’s not understanding the trade-offs,  especially when it comes to licensing.

Most teams don’t realise that D365 licences come with embedded Power Platform entitlements, or that standalone Power Apps licences don’t grant access to D365 apps or tables unless explicitly allowed.

So what happens?

You build a custom app. It works. Then a new requirement comes in like full Opportunity management or embedded AI suggestions, and suddenly, you hit a wall. Now you’re stuck either refactoring your app or backtracking into Dynamics 365, paying for features you’ve already replicated.

Meanwhile, no one’s really tracking whether your licence mix still makes sense.

Clarify the use case before choosing the tool

There’s no one-size-fits-all rule. But here are some guardrails that help.

Use Dynamics 365 when:

• You need rich, ready-made functionality (e.g. forecasting, SLAs, AI suggestions, complex case routing)

• You need proven process best practices, rather than designing and building them from scratch

• Your business processes match Microsoft’s domain models reasonably well

• You want native integrations with Microsoft tools like Outlook, Teams, LinkedIn Sales Navigator, or Copilot for Sales

• You’re okay with higher cost per user, in exchange for lower development overhead — depending on your specific needs

• You need certain customer features (e.g.: scheduling, webchat, or telephony integration)

• You are keen on getting Microsoft's new features and all the agentic/AI goodies coming our way

Use Power Platform when:

• You need to move fast, prototype quickly, or deliver something that doesn’t fit Microsoft’s mould

• You have lots of light-touch users who don’t need the full D365 UI or data model

• You want to create custom logic, UI, or automations that aren’t tied to first-party roadmaps

• You’re working in mixed environments where cost efficiency and control matter more than fancy out-of-the-box features
  

And here’s the thing: it’s not necessarily one over the other.

Combine both for flexibility

Most environments already do this, even if they don’t realise it. Dynamics 365 and Power Platform share environments. They share admin controls. They share security roles, Dataverse tables, and governance tooling. That means you can:

• Build custom Power Apps that live alongside D365

• Extend Dynamics with custom flows, plug-ins, and apps

• Use Power Pages for external users while keeping internal staff in Dynamics

• Mix licence types to match real usage (but make sure to avoid multiplexing)

The key is to align platform choice with actual team needs, not just what feels easier in the moment.

What about the future?

The Dynamics 365 vs. Power Platform debate is likely going to get even blurrier.

The number of partners shifting away from D365-first practices is growing. Some are openly saying they can build better, lighter-weight versions of Microsoft’s own apps using the same platform, without the first-party pricing.  

It’s clear the landscape is changing. Microsoft itself is pushing AI Agents, natural language interfaces, and modular, composable apps. The big SaaS era may be winding down, and that means your decision framework needs to adapt too.

Make the right choice for your business

There’s no universal right answer — only the right answer for your specific use case. A very high-level way to think of it:  

Use Dynamics 365 when you need depth, robust integration, and out-of-the-box functionality that’s purpose-built for business processes.  

Opt for Power Platform when agility, custom control, or cost flexibility are your top priorities.  

In practice, most environments benefit from a hybrid approach that leverages both. Just make sure you understand the licensing implications before you commit to one path or the other.

And above all: make the decision intentionally, not reactively.

Not sure which solution is best for your team? Get in touch to discuss your use cases.

Up next in our D365 Licensing series:  

• How to keep control over license sprawl in distributed teams

‍

TL;DR

Most Dynamics 365 environments are over-licensed because it’s easier to give everyone full access than map what they really need. That convenience quickly turns into wasted budget, as many users could be covered by cheaper Team Member or Power Apps licences without losing functionality. By starting with personas and using the CRUD framework to align licences with actual roles, IT Ops teams can right-size their setup, reduce costs, and stay compliant. The key is to differentiate between heavy users who need full Dynamics apps and light users who only need to read or update certain data. With the right governance, you avoid duplicate licences, reclaim unused entitlements, and make licensing a strategic lever for cost savings and smoother operations instead of an afterthought.

Full access to everyone? Why that D365 licensing shortcut costs you

“It’s easier to give everyone full access than figure out what they actually need.”

If that sounds like your current Dynamics 365 licensing strategy, you’re not alone. For many Operations teams, convenience wins: Full access for everyone, with little scrutiny.  

But that convenience comes at a cost.

One admin on Reddit realised that half of their 500 users likely didn’t need full Sales Enterprise licences. By reassessing needs and considering Team Member roles, they opened the door to major savings, without compromising on functionality.

This is the second part of our series. In our previous article, we discussed the basics of Dynamics 365 licensing.

In this post, we’ll show you how to avoid overspending by mapping licences to actual roles — not assumptions — using the CRUD framework and some simple steps.

Why most teams over-license by default

When you’re rolling out a CRM to a distributed workforce, many IT teams take the “just give them everything” approach:

• It’s quicker to provision

• It avoids user complaints

• It ensures access

But here’s the issue: most users don’t need everything. Let’s take field teams as an example:

• A sales rep logging notes or checking pipeline status? Probably fine with a Team Member or Power Apps licence.

• A dispatcher updating job status? Doesn’t need full Sales Enterprise.

Over time, these mismatches become expensive.

Start with personas, not products

Before assigning a single licence, step back and map your users by persona. Ask two questions:

1. What business role do they play? (e.g. Sales rep, dispatcher, technician)

2. What do they actually need to do in the system? (Use the CRUD framework: Create, Read, Update, Delete)
   

Then build a simple persona-functionality matrix. Here’s what that might look like:

Instead of starting with licence types, begin with actual user roles. This is an example of what it might look like:

Now you’re licensing based on what users do, not what they “might need someday”.

Use cases where Team Member or Power Platform wins

Let’s say you have:

• 10 partner managers or field reps managing opportunities full-time

• 100 extended team members like product, customer service, or sales support staff who just check status and log meetings

You don’t need 110 Sales Enterprise licences.

Instead, those 100 lighter users could use:

• Team Member licences for basic read/update interactions

• Power Apps per-user or per-app licences for custom tools

That change alone could lead to significant savings, while still enabling mobile access and compliance.

Don’t forget: Team Member licences have limits

Team Member licences are cost-effective, but they come with restrictions:

• Users can read any data but can only write to limited entities (e.g. contacts, notes, tasks)

• They’re limited to one Dynamics 365 app module and one custom app

• They don’t support premium plug-ins or complex automation

Tip: Create simple, dedicated apps for Team Member roles. For example, a “Sales Assistant” app that restricts functionality to what’s permitted.

Power Platform: The underrated licensing play

If your field users mostly use custom mobile apps — say, to:

• Record visit results

• Complete inspections

• Trigger automated workflows

…then they may not need a Dynamics 365 licence at all.

Instead, use Power Apps licences to:

• Access the same Dataverse instance (as long as those apps don’t rely on restricted entities like some Sales or Service records)

• Work with custom tables

• Run Power Automate flows

• Keep licensing flexible and compliant

For many field teams, this is the simplest way to reduce licensing costs while improving the user experience.

What to do next: Your 2025 licence optimisation checklist

• Audit your current licence usage
  Start with heavy vs. light users. Who really needs full access?

• Map access by role
  Build a persona-to-functionality matrix using the CRUD model (Create, Read, Update, Delete).

• Reassign based on real needs
  Don’t rely on legacy assignments. Right-size licences to fit current roles.

• Use Team Member licences wisely
  Apply only where read-only, self-service, or basic update access is sufficient.

• Deploy Power Platform licences
  Great for users who only need custom apps or limited interactions.

Avoid common traps

• Don’t use Power Apps licences to access D365 restricted entities
  Be careful: Sales, Field Service, Customer Service features and restricted entities are off-limits.

• Avoid duplicate licences across environments
  Check for sandbox or legacy orgs assigning unnecessary extra licences.

• Reclaim unused entitlements
  Track who actually logs in and remove licences from inactive or former users.

• Watch for multiplexing violations
  Sharing a single account across multiple users via Teams, SharePoint, or embedded apps? This is not allowed, and Microsoft is tracking it.

Licensing impacts more than your budget

Licensing isn’t just a budgeting decision — it’s an operational one. The wrong licence can block users, slow down processes, or waste tens of thousands annually.

Matching licences to how people actually work can reduce spend, streamline provisioning, and improve satisfaction for your mobile workforce.

Need help auditing your Dynamics 365 environment? Contact us to discuss your use case.

Up next in our D365 Licensing series:  

• D365 or Power Platform: Which one is right for your use case?
• How to keep control over license sprawl in distributed teams

‍

Disclaimer: This post is for informational purposes only and does not constitute formal licensing advice. Microsoft licensing is complex and subject to change — always refer to the official Microsoft Licensing Guides and consult with a qualified advisor (like us!) before making decisions.

‍

‍

TL;DR

Licensing issues are one of the biggest hidden causes of access problems in Dynamics 365. Even when users are assigned licences, they may still be blocked by missing environment permissions, misapplied base and attach licences, or silent capacity limits. For IT Operations teams, understanding the fundamentals — user, device, and tenant licences; base vs. attach logic; storage entitlements; and environment constraints — is key to keeping systems stable and budgets under control. Most over-spend comes from duplicate base licences, orphaned entitlements, or unused capacity left in old environments. Treat licensing as part of your core governance strategy, not an afterthought: map roles to licences, audit regularly, and align capacity with actual demand. Done right, licensing prevents downtime, keeps users productive, and ensures compliance as Microsoft tightens enforcement in 2025.

Dynamics 365 access: Is it a licensing issue or something else?

"We assigned the licence. Why can’t they log in?"

‍

For many IT Operations teams, managing Dynamics 365 feels like tiptoeing through a minefield of licences, environments, and entitlements.

One admin summed it up like this:

“We’re paying for licences, but people still can’t access what they need. I just want to keep the system running.”

Dynamics 365 licensing is confusing but makes sense once you understand the principles. Between base licences, attach licences, user vs. capacity models, and silent limits on environments, even experienced IT pros get blindsided.

This is the first part of our Dynamics 365 licensing series. In this post, we’ll break down the key licensing concepts that matter for IT operations in 2025, without repeating the entire Microsoft guide.

Why your users have licences but still can’t access D365

Let’s start with the most frustrating scenario: your users are licensed, but they still hit access errors.

Here’s why that happens:

• A licence doesn’t guarantee access to the environment. Users need permissions to the right environment and the underlying database.

• Some roles need more than one licence. A single app licence (like for Finance) might not be enough if the user also needs to work in another module (like Sales).

• Attach licences only work if you have a valid base licence. You can’t stack attach licences on a user without a qualifying base licence in place.
  

And don’t forget: environments and storage come with limits too. If the environment is out of capacity or misconfigured, licensing won’t save you.

D365 licensing basics

Here’s what actually matters to IT Operations teams:

The three licence types you’ll encounter most

• User licence: The most common. Tied to a named user.

• Device licence: For shared workstations or kiosks, especially in warehouses or retail.

• Tenant licence: Grants capacity (like storage or API calls) at the environment or tenant level.

Base vs. Attach licences

• Base licence: The first licence a user gets. It must be the most expensive one they need.

• Attach licence: Discounted licences for additional apps. Only valid if you have a base licence from the right product family.

Many teams overpay by assigning multiple base licences instead of using attach licences strategically.

“We’re cleaning up old users — what do we do with the licences?”

This is a common scenario. Old users are still active in Entra ID or assigned licences in the Microsoft 365 Admin Centre, but nobody’s checked if they even use the system.

Here’s what we recommend:

• Audit licence assignments quarterly. Look for inactive users still assigned premium licences.

• Clean up orphaned access. If a user has been removed from Dynamics but still exists in Entra ID with a licence, that’s wasted spend.

• Map access by role, not by person. Don’t assign licences just because “that’s what they had before.” Reassess by function.
  

Start with Team Member licences for light users — just make sure their access needs fall within its limits (read-only, self-service, or basic workflows only).

Are we paying for duplicate licences across environments?

Short answer: probably. Here’s how to spot waste:

• Check for users with licences in multiple environments, especially sandbox copies or legacy orgs that no one cleaned up.

• Review capacity add-ons — many are environment-bound and often over-provisioned.

• Look at attached Power Platform licences. Are you paying for capacity through both Dynamics and Power Apps? You might be.

Storage maths in a nutshell

• Each full user licence gives you 10 GB of database storage

• Every user adds 250 MB extra

Need more? You’ll have to buy additional capacity.

Three tech stacks = three licensing mindsets

Dynamics 365 isn’t one piece of software or application. It’s a suite with different behaviours and pricing models:

1. Customer Engagement Apps: Sales, Customer Service, Field Service — often used together, but watch out for duplicate entitlements.

2. Business Central: Sold as a bundle. Easy to manage, but not as flexible with attach licences.

3. Finance and Operations: High-value, high-cost — and the source of many of the trickiest licence combinations (Finance alone is £180/user/month).
   

Each stack handles users, storage, and automation differently. If you’re mixing these, map your licensing strategy accordingly.

Licensing isn’t just compliance

Many access issues, slow processes, or broken workflows are actually licensing issues in disguise:

• Overloaded storage = system slowdowns

• Misassigned licences = user lockouts

• Missing entitlements = failed automations

Licensing is now directly tied to performance. Microsoft is enforcing this more aggressively, especially for Team Member misuse and capacity overages.

Your 2025 checklist for cost-efficient Dynamics 365 licensing

• Audit users and licences: Identify who has what, where, and whether they actually use it.

• Map roles to licence types: Use role-based access and the CRUD model to assign only what’s needed. (More on CRUD in our next post!)

• Use Attach licences wisely: Don’t pay for multiple base licences — add attach licenses where eligible.

• Clean up unused environments: Retire or merge low-use or duplicate instances.

• Align storage to actual need: Remove excess capacity and avoid default overprovisioning.

• Consolidate across teams: Prevent duplicated licensing in siloed regions or departments.

• Reclaim unused licences: Remove entitlements from inactive or former users.

• Review quarterly: Make licence audits a recurring practice, not a one-off cleanup.

• Monitor Microsoft policy changes: Stay compliant by keeping up with evolving licensing rules.

Don’t let licensing be an afterthought

You don’t need to master every nuance of Microsoft’s licensing. But you do need to understand the mechanics that impact performance and budget.

Licensing should be among the first priorities in your Dynamics 365 environment, right alongside security, data, and automation.

Need a health check on your setup?
Request a free audit and make sure you’re not leaving money (or performance) on the table.

Up next in our D365 Licensing series:  

• How to right-size your D365 licenses by aligning them with actual user roles

• D365 or Power Platform: Which one is right for your use case?

• How to keep control over license sprawl in distributed teams

‍

TL;DR:

Copilot Studio has officially moved out of the Power Platform Licensing Guide into its own dedicated document — a quiet but meaningful change introduced in June 2025. While the usage-based model remains the same, the separation signals Microsoft’s shift toward standalone, consumption-driven pricing for AI tools. Copilot Studio now has its own guide detailing billing rates, usage estimators, and agent activity costs, while all major references have been removed from the Power Platform guide. For IT operations and licensing teams, this marks the start of a broader transition to pay-per-use models across Microsoft’s ecosystem. Keep both guides updated, watch for usage-based billing creep, and prepare for renewals that reflect this new AI-first licensing era.

New guide, same usage-based model

There’s been a quiet but important shift in Microsoft’s licensing documentation. If you’ve been tracking the Power Platform licensing guide over the past few months, you might have noticed something in the June 2025 edition: Copilot Studio is gone.

In short: Copilot Studio has “graduated” out of the Power Platform PDF and now lives in its dedicated guide.

As Jukka Niiranen noted, Microsoft has released a dedicated Copilot Studio Licensing Guide that consolidates information previously scattered across Microsoft Learn articles, pricing pages, and various Power Platform PDFs.

There was no formal announcement of this change, just a quiet footnote in the June 2025 Power Platform change log:

"For Microsoft Copilot Studio licensing information, please refer to the Microsoft Copilot Studio Licensing Guide."  

What’s in the new guide?

• How to buy Copilot Studio

• Billing rates for agent activity and AI tools

• A usage estimator

• Licensing scenarios (e.g. trials, enterprise deployment)

• Details on Dataverse, Managed Environments, multiplexing

• Appendices on billing, preview terms, terminology and change log

And what’s changed in the Power Platform guide?  

As Jukka pointed out, most references to Copilot Studio have now been removed. Only a few mentions remain in the change log, likely a sign that the transition is still in progress.

Importantly, there are no changes to the underlying licensing model at this time. Copilot Studio continues to follow usage-based billing:

• Agent messages

• AI tool calls

• API usage

All contribute to billed consumption.

Why it matters: Are we phasing out Power Platform… or phasing in pay-per-use?

This might seem like a minor update to documentation, but it points to a bigger shift. Microsoft is carving out its high-value tools like Copilot Studio into standalone billing structures, separate from the Power Platform umbrella many organisations still depend on.

In a LinkedIn post, Roberto Lofaro recalled earlier transformations in software licensing:

• From 1980s maintenance fees (that sometimes continued even after updates stopped),

• To project-based and license-based SaaS in the 1990s,

• To today’s consumption-first models.

We’re moving closer to a model where AI features become embedded in every desktop and mobile tool and incur usage charges whenever they connect to cloud services. Think of Copilot in Office or even WhatsApp integrations that quietly activate background AI.

In Roberto’s words, "It is almost a Chromebook model: you can activate the offline use, but will lose features”.  

In short, key features will only work when connected, and often at a cost.

What to watch out for (especially if you're in IT Ops)

As Copilot Studio moves into its own licensing framework, here are a few things to keep on your radar:

• Update cycles: Don’t rely on the Power Platform guide alone. Keep track of the standalone Copilot Studio guide, it is likely to receive more frequent updates.

• Broken references: If your internal documentation or procurement materials still reference Copilot Studio under Power Platform, it’s time for an update.

• Pay-per-use creep: Be cautious about where AI usage might trigger billing. Even features that seem low-touch may generate billable events.  

• Preview ≠ free: Not all preview features are cost-free. Some already contribute to billed usage, especially in environments with connected data.

Keep track of your usage. You can use the Copilot Studio agent usage estimator (still in preview).

Your next Microsoft renewal might look very different

Microsoft is reorganising its licensing playbook to support an AI-first future. Copilot Studio getting its own guide is more than a formatting choice — it signals a broader shift toward usage-based pricing models.

If you’re involved in IT operations, licensing, or governance, keep an eye on these developments. Especially before your next renewal.

The bottom line is: Microsoft’s pricing structure has been changing a lot recently. Want to optimise licenses before your upcoming renewal? Contact us to discuss your use case.

‍

TL;DR:

Scaling Power Platform is a sign of success—but without oversight, it can quickly become expensive. In 2025, evolving Microsoft licensing models mean that unmonitored growth, unused licenses, or redundant tools can drive costs up fast. The post explains how to scale sustainably by monitoring usage regularly, designing modular apps that adapt to licensing changes, and running health checks to catch “zombie” apps or high-cost flows. It also emphasizes assigning clear ownership for cost management and avoiding vendor lock-in by keeping solutions flexible. Smart scaling means growing capability—not cost.

Scaling your Power Platform usage is a good problem to have

It means your teams are building, automating, and delivering value. But unchecked growth comes with hidden costs. As Microsoft evolves its licensing models, small missteps can snowball into big expenses.

In this blog post, we discuss how to scale in a sustainable way, design cost-aware apps, and stay in control as pricing and features shift. Whether you’re running a Center of Excellence or simply supporting teams building apps, the goal is the same: grow smart, without overspending.

This is the fifth part of our Power Platform licensing series. In our previous articles, we covered

• Microsoft Power Platform licensing changes in 2025 and how they affect users,

• Power Platform Licensing Within M365 & D365 and what bundled access actually includes

• Standard vs. Premium Connectors in Power Platform and how to stay ahead of changes

• Request management in Power Platform and how to stay within limits and budget

Stay informed: Monitoring licensing and usage

One of the most important habits you can build is regular visibility into what you’re using and what it costs. Microsoft licensing isn’t static — new SKUs are introduced, entitlements change, and API pricing evolves behind the scenes. If you’re not watching, you’ll miss the early signs of budget creep.

Start by subscribing to Microsoft’s release notes and licensing update blogs. These updates often include connector reclassifications or entitlement adjustments that can quietly impact your costs. Set internal reminders to review licensing guidance at least once per quarter.

On the internal side, the Power Platform Admin Center provides recent usage data to help you:

• Track how many users are actively using licensed features

• Identify which apps or flows are consuming the most requests

• Flag spikes in usage that could trigger overages

While Azure Monitor doesn’t directly track Power Platform request usage, it can complement your monitoring strategy by alerting on related Azure services, such as API Management or custom connectors, based on available metrics and logs.

This isn’t just about control, but also about building confidence that your investments are being used effectively.

Build apps with the future in mind

Great app design doesn’t just improve performance, it also reduces risk when licensing rules change.

When building or reviewing solutions, favour modular architecture. Why?  

Modular apps are easier to adapt if Microsoft reclassifies a connector or changes how a feature is billed. For example, separating a high-volume automation into its own flow makes it easier to isolate and scale independently.

Be strategic about Premium connector usage. If your team already relies on connectors like Dataverse, SQL Server, or custom APIs, continue using them where they add value. But if you're considering Premium for the first time, evaluate whether the business impact justifies the added cost. Either way, design flows to avoid unnecessary steps or repetitive API calls that can drive up request consumption.

As part of your development standards, document each app’s licensing and connector dependencies. When it comes time to upgrade, scale, or refactor, this documentation will save time and prevent guesswork. If you're using the Center of Excellence Starter Kit, it automatically tracks which connectors each app and flow uses — and whether they’re Standard or Premium.

Run regular health checks for smarter spending

Apps and flows don’t stay static and neither should your approach to managing them.

Establish a regular cadence for cost and usage audits. Monthly or quarterly reviews can reveal:

• Licensed apps that haven’t been used in months (“zombie apps”)

• Flows that run frequently but no longer serve a real purpose

• License assignments that don’t match actual user activity

You’ll also want to conduct scaling impact reviews. What happens if app usage doubles next month? Or a department adopts Power Platform for the first time? Use Microsoft’s licensing calculators and cost simulators to predict these shifts before they happen. A little forecasting now can save you a budget surprise later.

Avoid lock-in while leveraging the ecosystem

When scaling on Power Platform, it’s tempting to take full advantage of every integration and customisation feature available. That’s the power of the platform, but it can also create hidden long-term costs.

There’s a difference between vendor alignment and vendor lock-in.

Alignment means taking advantage of Microsoft-native tools like Dataverse, Teams, and Azure for greater cohesion. Lock-in happens when your solution becomes so custom that migrating or adjusting becomes painful or expensive.

Whenever possible, keep business logic inside Power Platform, but design your data to be portable. Avoid overly rigid dependencies on proprietary formats or niche connectors unless they’re business critical.

Audit the tools you’re already paying for

Another source of cost creep is tool redundancy. Teams often spin up new software without realising that the same functionality exists within the Power Platform or adjacent Microsoft 365 tools.

Make it part of your governance model to review the full ecosystem regularly. Ask:

• Are multiple analytics tools in use across the same team (e.g., Power BI and Tableau)?

• Are there legacy tools still active despite being replaced by Power Apps or Automate?

• Are business units buying new solutions instead of using licensed ones already available?

Encourage teams to maximise existing investments before expanding into new tools.

Assign ownership to stay ahead

One of the most effective things you can do to control costs is assign a cost and usage owner. Without clear ownership, monitoring tends to fall through the cracks, especially when budgets are shared across departments.

This person (or small team) doesn’t need to manage licenses day-to-day. But they should be responsible for:

• Tracking usage trends

• Monitoring request volumes and license consumption

• Preparing quarterly usage reports

• Advising on renewals, upgrades, or plan changes

Proactive cost management is only possible when someone is paying attention to the right data at the right time.

Final thoughts: Maximise value without overspending

Scaling Power Platform doesn’t have to mean growing your budget at the same pace. With the right practices in place, you can expand your impact while keeping costs predictable and controlled.

Keep these principles in mind:

• Monitor usage regularly and stay up to date with licensing changes

• Design apps with flexibility and long-term efficiency in mind

• Assign ownership so cost and usage insights turn into action

Smart scaling isn’t just about handling growth, it’s about making every cent you spend work harder.

We hope you’ve found our series on Microsoft Power Platform licensing helpful.

Looking to scale your Power Platform usage without overspending? Contact us to discuss your use case.

‍

TL;DR:

When apps or flows stop without warning, request limits are often the cause. Every action counts as a request, and in 2025 Microsoft enforces these limits strictly — once exceeded, flows fail and data sync slows. The post explains how requests are measured, how to monitor them in the Admin Center, and how to scale safely. Track usage early, refactor high-volume flows, assign Per Flow licenses to service accounts, and make request management part of your governance to avoid unexpected throttling.

Have your apps or flows stopped working without warning?

‍
There’s a good chance request limits were the culprit.

In Power Platform, every time a user saves a record, triggers a flow, or calls a connector, it counts as a request. Individually, these seem small. But as usage grows, so does the number of requests, and eventually, you’ll hit your limit.

As a result, bandwidth control kicks in, you get notified of failed runs or denied access that seem to come out of nowhere. And once again, it’s up to the operations team to figure out what happened and how to fix it.

In this post we’ll look at how request limits work in 2025, how Microsoft enforces them, and most importantly, how your team can stay compliant.

This is the fourth part of our Power Platform licensing series. In our previous articles, we covered

• Microsoft Power Platform licensing changes in 2025 and how they affect users,

• Power Platform Licensing Within M365 & D365 and what bundled access actually includes

• Standard vs. Premium Connectors in Power Platform and how to stay ahead of changes

Why request limits in Power Platform shouldn’t be taken lightly

In early versions of Power Platform, request limits were often overlooked. Enforcement was loose, and most apps never came close to hitting the thresholds.

That’s changed. Microsoft now treats request usage as a core part of license entitlement.  

Every license type includes a defined number of daily requests per user or flow, and enforcement is no longer optional. Whether you’re using Power Apps, Power Automate, or Dataverse, request volumes are tracked, monitored, and capped.

How Microsoft measures requests in 2025

Every interaction with the platform counts as a request. That includes:

• Saving or retrieving data from Dataverse, or any other data source

• Calling connectors (Standard or Premium)

• Each action step (which goes outside of your Power Automate) while running flows

• Triggering plug-ins or custom APIs

• Even system-level operations like lookups and validation

Microsoft provides a detailed breakdown of request capacity by license type. For example, users with a Power Apps Per User plan get a higher daily request limit than those using a Microsoft 365 license with Power Apps access. Background flows, unattended automation, and service accounts with Per Flow licenses have their own request pools.

What’s new in 2025 is how Microsoft surfaces this information

The Power Platform Admin Center now allows you to see request usage per user, environment, and app, but it takes a few steps to find the data. To check your request allocation, follow these steps:

1. Log in to the Power Platform Admin Center.

2. Navigate to the "Capacity" section in the left-hand navigation pane.

3. On the summary tab, look for the option to download reports (often found in an "Add-ons" or similar section).

4. Select "Download reports" and choose the type of report you want, such as "Microsoft Power Platform Requests."

5. Choose the scope for your report (e.g., Licensed User, Non-Licensed User, or Per Flow Licensed Flows).

6. Submit and download the report to view detailed usage data for each user or flow, including how many requests have been consumed.

You can also use Azure Monitor to set up alerts, but it does not natively track or alert on Power Platform request usage or allocation from the Power Platform Admin Center. Instead, it’s primarily built for observing Azure-native resources, such as virtual machines, databases, and Azure API Management, and can trigger alerts based on metrics or logs collected from those services.

What happens when you hit the limit

Request limits aren’t just theoretical. When usage exceeds your allocated capacity, Microsoft enforces throttling. Depending on the service and workload, this can mean:

• Flows that fail to trigger or complete

• Delays in data syncing or processing

• Errors when users try to save or update records

These disruptions can affect frontline business processes, like approvals, customer onboarding, or field updates, leaving teams confused about why things broke.

Most throttling surprises happen because teams aren’t actively tracking request consumption until it’s too late. To make matters worse, there's rarely a visible warning for end users. They just see errors. By the time IT gets involved, the platform may have already been throttled for hours.

How to manage requests proactively

The best way to manage request limits is to stop thinking of them as an afterthought. Request planning needs to be part of your architecture discussions from day one. Start by understanding your baseline. Use the Admin Center’s analytics to monitor which apps and flows are consuming the most requests.  

Look for patterns: Is usage spiking during certain times of day? Are a few apps responsible for the majority of consumption?

Once you have visibility, you can make smarter decisions, such as:

• Refactoring flows to reduce unnecessary steps or loops

• Offloading complex logic to Azure functions or other services where appropriate

• Consolidating data calls to reduce repetition

You don’t need to over-optimise from the start. But you do need to understand where your limits are and have a plan for what happens when you approach them.

How to plan for scale

As adoption grows, request volumes will too. But without a scaling strategy, your success can start to work against you, pushing you past request limits.

Microsoft offers a few options for scaling request capacity:

• Per App and Per User licenses each include defined request limits

• Pay-As-You-Go plans allow flexible scaling, with request overages billed through Azure

• Add-on request packs allow organisations purchase extra capacity without changing license types  

The right option depends on your usage profile. High-volume solutions used by a small group may benefit from Pay-As-You-Go. Department-wide apps might justify more robust licensing.  

(Note: Currently all organisations are in transition period with higher request limits. The transition period ends after Power Platform Admin Center reports are generally available. Organisations then have six months to analyse their usage and purchase licenses that are appropriate before strict enforcement on license limits begins. More info here.)

Don’t let service accounts become bottlenecks

A common pain point for many teams is the use of service accounts or shared automation users. These accounts often own high-volume flows or integrations, but they come with a fixed request limit, just like any other user.

When you hit those limits, automation fails, even if every individual user is well within their allowance.

The solution is to assign Per-Flow licenses to critical service flows. This plan reserves dedicated capacity for each licensed flow, regardless of who owns or triggers it, and does not consume from the tenant’s non-licensed user request limits.

It’s also a best practice for long-term maintainability, as it decouples business logic from individual users and ensures key automations remain stable over time.

Make request management part of governance

If you’re running a Center of Excellence or managing a large Power Platform deployment, request limits need to be part of your governance model.

That means:

• Including request tracking in solution review checklists

• Training makers to understand how their design choices affect request usage

• Defining escalation paths for throttling issues

• Monitoring usage trends and forecasting future needs

Build smart, scale smoothly

Request limits aren’t just technical constraints. They’re signals that your platform usage is growing and needs more intentional design. By understanding how requests work, monitoring them proactively, and scaling smartly, you can keep apps running smoothly and avoid the surprise of throttling.

Not sure what the right licensing setup is for you? Contact us to discuss your use case.

Up next in this series:

• Smarter spending with Power Platform — Managing costs for future scaling

‍