The Power Apps Per-App Plan Is Retiring. It’s Forcing Overdue Power Platform License Optimization.

IT director and finance director reviewing a Power Platform license usage dashboard on a large office monitor

An IT director at a distribution company got her Power Platform renewal quote back in August and the per-app line item had a note attached: new purchases under that SKU were no longer available through her Enterprise Agreement’s normal channel. She had eleven apps running on per-app capacity packs, covering everything from a driver check-in tool to a rebate approval workflow, and nobody on her team had ever audited whether those apps still needed dedicated capacity or whether half their users had moved to other roles. The renewal conversation, which was supposed to be a formality, turned into a scramble to figure out what she was actually paying for, and into the kind of overdue Power Platform license optimization exercise most IT organizations keep putting off until a contract forces it.

IT director and finance director reviewing a Power Platform license usage dashboard on a large office monitor

That scramble is becoming common. Microsoft ended new sales of the Power Apps per-app plan on January 2, 2026, and the way that retirement plays out depends entirely on which purchasing channel an organization uses: Enterprise Agreement customers can keep renewing and adjusting counts through their normal true-up process, MPSA customers lose access to the SKU when their current agreement expires and get sixty days to move to something else, and CSP customers were largely unaffected, with the plan returning to availability there in early April. Three different outcomes for the same retirement, depending on how procurement happens to be structured, is exactly the kind of detail that gets missed until a renewal quote forces the question.

The timing matters because it coincides with something genuinely useful: Microsoft has finally shipped a way to see what a Power Platform license estate is actually being used for, instead of relying on procurement records and institutional memory. Getting that visibility in place before the next renewal cycle is the difference between a defensible Power Platform license optimization decision and another round of guessing.

Why Power Platform License Optimization Has Been Mostly Guesswork

Until recently, an organization trying to right-size Power Apps and Power Automate licensing had to stitch together the answer from several disconnected places: the Microsoft 365 admin center for what was purchased and assigned, PowerShell exports like Get-AdminPowerAppLicenses for a point-in-time snapshot, and whatever the CSP or EA reseller could pull from their own systems. None of those sources actually answered the question a CFO cares about, which is how many of the licenses being paid for are being used by someone doing real work in a given month.

The license consumption experience now available (in preview) inside the Power Platform admin center closes that gap. Under Licensing, administrators can pull up Power Apps and see, side by side, per-user licenses purchased against per-user licenses actually consumed by someone who launched an app in the last 90 days, per-app licenses allocated to environments against what was purchased, and any pay-as-you-go billing plans linked in the same view. It breaks down by environment as well as organization-wide, and it will export a CSV of active users, their last app launch, and which license type they used to get in. For an IT director trying to answer “do we actually need eleven per-app packs,” that is the first time the honest answer has been sitting in one screen rather than scattered across three systems and a spreadsheet someone built two years ago.

There is a companion version of this reporting for Dynamics 365 Finance and Operations environments connected through the Power Platform admin center, and it is worth calling out separately because F&O licensing carries its own compliance exposure that per-app and per-user Power Apps licensing does not. That report maps security roles to license requirements and flags users who are under-licensed for the roles they hold, over-licensed relative to what they actually use, or missing a license entirely despite having role access. For a finance organization worried about a true-up or compliance review turning up unlicensed F&O access, that role-to-license breakdown is arguably more valuable than the Power Apps consumption view, because F&O license gaps carry direct compliance risk rather than just wasted spend.

Two enterprise IT professionals reviewing a printed license usage report and laptop dashboard during a renewal discussion

What This Changes About the Renewal Conversation

None of this reporting makes the decision automatically. It gives a CIO or CFO the input needed to make a real one, and there are three moves worth having on the table before the next renewal.

The first is treating the per-app retirement as a forcing function to re-evaluate whether per-app capacity was ever the right model for those specific apps in the first place, rather than assuming the goal is simply to find a like-for-like replacement. An app used constantly by a stable group of forty employees usually still makes sense on a capacity or per-user model. An app used sporadically by three hundred people across the organization, the kind of low-frequency, wide-distribution use case Microsoft explicitly points pay-as-you-go at, is often cheaper and administratively simpler on a consumption model tied to an Azure subscription, where there is no license procurement cycle at all and the organization pays only for sessions that actually happen.

The second is using the consumption report before, not after, the renewal negotiation. A vendor conversation about right-sizing an estate is a different conversation when the buyer walks in with an export showing which per-app allocations have had zero active users in the trailing ninety days versus one built on assumptions. That data also gives Finance a defensible basis for the true-up number instead of an estimate carried forward from the prior year.

The third is recognizing that pay-as-you-go billing plans allow granular cost allocation that traditional licensing does not. Because a billing plan links specific environments to an Azure subscription, and because Azure’s own cost management and resource tagging can then split charges by team or department, an organization running Power Platform across multiple business units can get a real chargeback model instead of a Power Platform budget line that IT absorbs and never breaks down by consumer. That is a meaningfully different conversation for a CFO than “the Power Platform bill went up again this year.”

What to Do Before the Next Renewal

For an organization anywhere in the Power Platform per-app transition, the practical sequence is straightforward even if the underlying decisions are not. Pull the license consumption report for Power Apps and, if applicable, the F&O consumption report, before assuming a renewal quote reflects actual need. Segment the app portfolio by usage pattern rather than by however licenses happen to be allocated today, since a capacity pack purchased three years ago for a pilot may now be covering an app that either died quietly or scaled to a very different usage profile. Confirm which purchasing channel governs the organization’s contracts, since an EA customer facing no disruption and an MPSA customer facing a sixty-day migration window are working against very different timelines, and the MPSA customer in particular should not wait for the renewal notice to start that conversation. And treat pay-as-you-go as a genuine option for the specific subset of apps that fit its profile, rather than a fallback only considered after per-user and per-app options are exhausted.

None of this requires a platform migration or a change to how the apps themselves work. It requires pulling data that, for the first time, is actually sitting in one place, and using it to make a licensing decision on facts rather than habit. Organizations that have gone through a Power Platform license optimization exercise with us tend to find the same thing: the spend was rarely wildly wrong, but it was almost never right, and the gap between those two states is usually worth the afternoon it takes to run the report.


Routeget Technologies works with IT and finance teams on Power Platform governance and licensing reviews as part of broader Dynamics 365 and Power Platform engagements.


#PowerPlatformLicensing #LicenseOptimization #PowerAppsPerApp #PayAsYouGo #PowerPlatformGovernance #ITCostGovernance

Dynamics 365’s Free Sentiment Analysis Has a Blind Spot. AI Builder Sentiment Analysis Can Close It, at a Cost.

Customer experience team reviewing a sentiment analytics dashboard on a large monitor

A customer experience director at a mid-market distributor recently asked her Dynamics 365 partner for something that sounded simple: one ranked list of accounts trending toward churn, built from every piece of customer feedback the company already collects. Support conversation transcripts, service case notes, post-delivery satisfaction surveys, and the freeform comments account managers leave on Opportunity records all already exist somewhere in her Dataverse environment. She assumed the sentiment analysis her team had seen in Customer Service demos would simply read all of it. It doesn’t. Dynamics 365’s built-in sentiment analysis is real, it works well, and it costs nothing extra to use, but it only sees what happens inside a case or an email thread. Everything else on her list, the surveys, the account notes, the reseller complaints logged in a spreadsheet, sits entirely outside its reach. Closing that gap means turning to AI Builder sentiment analysis, a separate tool, and that is a deliberate build, not a setting an admin flips on.

That distinction gets lost in a lot of planning conversations, because “Dynamics 365 has AI-powered sentiment analysis” sounds like one complete capability. It is actually two separate tools, the sentiment monitoring built into Customer Service and the standalone AI Builder sentiment analysis model, with different reach, different cost structures, and different governance obligations. Confusing the two is how a CX program either overpromises what a pilot will cover or underuses a tool that is already paid for.

What Dynamics 365 Already Gives You, Free

Native sentiment analysis in Customer Service is enabled by default and configured through the admin center’s Insights settings, where a supervisor can turn on real-time monitoring in a few clicks. Once it’s on, service representatives see a live sentiment reading during an active omnichannel conversation, with configurable alert thresholds ranging from “slightly negative” up to “very negative,” and supervisors get their own notification settings so they can step in on a conversation that’s deteriorating before it becomes an escalation. Historical scoring rolls up into Omnichannel Insights dashboards for after-the-fact analysis, and the feature covers more than forty languages out of the box. As of a May 2026 release, Microsoft extended the same underlying capability to email: incoming customer messages now get scored for tone before a representative drafts a reply, and that email-level sentiment rolls into a unified case sentiment score alongside conversation data. None of this requires AI Builder, a Power Automate flow, or a separate licensing conversation. It is part of the platform a Customer Service organization is already paying for.

Where the Built-In Tool Stops Seeing Customers

The scope of that native feature is narrower than most stakeholders assume. It is wired specifically to the Case, Conversation, and Email Message records inside Customer Service, and nothing that lives outside that data model gets touched by it. A satisfaction survey captured through a Power Pages portal or a Customer Voice form sits in its own tables. Freeform notes an account manager keeps on an Opportunity or Account record are just text fields, invisible to a sentiment engine that only looks at cases. A complaint a reseller emails to a partner manager, rather than filing through a support channel, never becomes a case at all. Social commentary or review-site feedback pulled in through a connector has no case or email record to attach a score to. In the distributor’s situation, most of the feedback her CX team actually cared about lived in exactly these gaps, which is why the demo she’d seen didn’t match the reality of her own data.

Solution architect building an automated sentiment scoring flow on a laptop

What AI Builder Sentiment Analysis Adds That the Native Tool Doesn’t

This is the actual role for AI Builder sentiment analysis, and it is worth being precise about what kind of tool it is. It’s a standalone prebuilt model, not a Customer Service feature, callable from a Power Automate flow or through a Power Fx formula in a canvas app, and it has no built-in awareness of cases or email at all. It accepts up to 5,120 characters of text per call and returns a document-level classification of positive, negative, neutral, or mixed sentiment, along with a confidence score and, if needed, a sentence-by-sentence breakdown. It supports a solid set of languages, including English, Spanish, French, German, Italian, Portuguese, Dutch, Japanese, Korean, Chinese, Hindi, Turkish, and Norwegian. Because it’s just a callable action with no opinion about where its input comes from, a flow can point it at a Customer Voice survey response table, a custom “Account Note” column, a SharePoint list, or an inbox that never turns into a formal case. That flexibility, not any difference in accuracy, is the actual reason to reach for it: it lets an organization build the one unified sentiment signal the CX director wanted, rather than settling for whatever slice of the customer relationship happens to fall inside a Case record.

The Rate Limit and Credit Shift Worth Budgeting For

Two constraints deserve attention before anyone commits a rollout date. The first is technical: the sentiment analysis, language detection, and key phrase extraction prebuilt models share a single throttle of 400 calls per 60 seconds within an environment. That ceiling is comfortable for scoring cases and emails as they trickle in throughout the day, but it gets hit fast the moment someone tries to backfill a year of Opportunity notes or process five thousand quarterly survey responses in one overnight batch. This is usually the first thing that breaks when a “score everything” mandate meets real data volume, and it should shape the flow design from the start, through pacing, delay steps, or triggering only on new and changed records instead of reprocessing history, rather than getting discovered during a failed pilot.

The second constraint is financial, and it connects to a transition already underway across AI Builder. Sentiment analysis is now billed under Microsoft’s “text and generative AI tools (Basic)” capability, and its licensing is migrating from AI Builder credits to Copilot Studio credits, with AI Builder capacity add-ons and any seeded credits in premium licenses reaching end of life on November 1, 2026. Any budget built for a sentiment-expansion project running into next year should be modeled against Copilot Studio credit consumption, not against a credit pool that Microsoft has already scheduled to stop selling.

A Practical Pattern for Extending Coverage

The build itself is not complicated once the source data is identified. A Power Automate flow triggers on new or changed rows in whichever table holds the text, whether that’s a survey response, a custom account-note table, or a Power Pages-submitted complaint form, calls the AI Builder sentiment action, and writes the resulting classification and confidence score back to a column on that record. From there, a condition branch can raise a Dataverse task for the account owner when a result comes back strongly negative above a chosen confidence threshold, and a Power BI report can rank accounts by a rolling sentiment average pulled from every connected source, not just cases. That report is what actually answers the CX director’s original request. The one governance step teams tend to skip is consent: because this reaches customer-identifiable text outside the flow Customer Service already governs for case and email sentiment, legal and IT should extend the same notice-and-consent practice to whatever new source gets added, rather than assuming existing sentiment monitoring approvals already cover it.

What to Confirm Before Committing

Three things are worth verifying before committing. The inventory of where sentiment-bearing text actually lives outside the Case and Email Message tables determines whether this is a two-week Power Automate build or a multi-source integration project, so it belongs at the start, not mid-pilot. Realistic call volume needs to be estimated against that 400-call, 60-second shared limit before a rollout date gets promised to a business sponsor, because a mismatch there turns a promising pilot into an incident in its first week of production use. And finance should weigh whether the Copilot Studio credit model makes sense at the organization’s expected volume compared with calling Azure AI Language directly through a custom connector, since at higher volumes the direct route sometimes costs less and gives more control over batching, even though it takes more setup than the point-and-click AI Builder action.

Dynamics 365’s native sentiment analysis, especially now that it reaches into email as well as live conversations, already covers most of what a typical service organization needs, and it’s worth using as it stands before building anything on top of it. The gap only becomes a problem when an organization wants one sentiment signal spanning every channel a customer actually uses, most of which never turns into a case. AI Builder sentiment analysis is the right tool for that expansion, but it comes with a real throughput ceiling and a licensing model mid-transition, not a checkbox next to a feature Microsoft already includes. Teams at firms like Routeget Technologies that have wired sentiment scoring into Dataverse tables outside the standard Customer Service model tend to start with that inventory step, because it’s usually where the real scope of the project gets decided, before anyone opens Power Automate.


#AIBuilder #DynamicsCustomerService #PowerAutomate #ChurnPrevention #CustomerExperience #EnterpriseAI #Dataverse