Configuring Cost Estimate Revenue Recognition in Dynamics 365 Project Operations

Finance professional reviewing a project revenue recognition dashboard in a modern office

A Project Operations consultant closing out a nine-month fixed-price engagement watches the percentage-of-completion figure move in a direction nobody on the delivery team predicted: down. Hours logged in August exceeded July. Actual costs tracked to plan. And yet the estimate-at-completion number jumped, because a resource manager quietly revised a forecast line two weeks before close, and revenue recognized in July has to be partially reversed to correct it. Finance wants to know why a project that delivered more work somehow recognized less revenue. The honest answer, until now, has been some version of “that’s how EAC-based recognition works.” As of September 11, 2026, that is no longer the only answer available. Microsoft has moved cost estimate revenue recognition in Dynamics 365 Project Operations to general availability, giving project accounting teams a second calculation baseline that does not move every time someone touches a forecast.

Why EAC Made Revenue Recognition Unpredictable

Fixed-price projects using the percent-completion method calculate recognized revenue as a share of total contract value, driven by percentage of completion. Under the standard approach, that percentage is actual costs incurred divided by the estimate at completion, and EAC is a living number. Every time a project manager updates a forecast line, adjusts a resource assignment, or revises an expense estimate, the denominator in that calculation shifts. A team can deliver exactly the work it planned to deliver in a given period and still see recognized revenue swing, purely because someone updated a forecast that has nothing to do with what actually happened that month.

Consider a $180,000 fixed-price contract line. Two months in, the team has incurred $54,000 in actual cost, tracking cleanly to a 30 percent completion rate against the original estimate. Then a resource manager flags scope creep on an upcoming deliverable and revises the EAC upward to $210,000. Recompute the percentage against the new denominator and completion drops to roughly 26 percent, even though nothing changed about the work already delivered. Finance now has to explain a revenue reversal to a client or an auditor for a project that is, by every operational measure, on track. Multiply that across a portfolio of active fixed-price engagements and month-end close turns into a chase for forecast revisions rather than a review of actual delivery.

Solution architect configuring project accounting revenue recognition settings

What Cost Estimate Revenue Recognition Changes

The new method replaces EAC in that denominator with a cost estimate: the original forecasted or budgeted total cost for the project, set once and held fixed unless someone deliberately revises the baseline. Percentage of completion becomes actual costs incurred divided by total forecast amount, full stop. Using the same numbers as above, the $54,000 in actual costs against the original $180,000 estimate still shows 30 percent completion in month two, regardless of what happens to the EAC afterward. If costs eventually run past the original forecast, the system does not reinterpret that as new revenue to recognize. It treats the overrun as margin erosion, which is arguably closer to what actually happened: the team spent more to deliver the same contracted scope, and that gap should show up as reduced profitability, not as a phantom revenue swing.

That distinction matters more than it sounds. EAC-based recognition quietly conflates two separate questions: how much revenue should be recognized this period, and how is the project trending against its budget. Cost estimate revenue recognition splits them apart. Revenue recognition stays anchored to the contracted baseline; budget performance becomes a separate conversation that shows up in variance reporting rather than in the revenue line itself.

Configuring the Feature: Cost Templates and Parameters

Enabling this requires Dynamics 365 Finance version 10.0.48 or later, along with the feature flag “Enable Project Revenue recognition by using the cost estimate instead of the estimate cost at completion in Project Operations,” which any user, admin, maker, or analyst with the right permissions can turn on through feature management. That self-service enablement path is worth flagging to your change control process on its own, since it alters financial calculation logic rather than a UI element, and it deserves the same review rigor as any other change to how revenue gets recognized.

Once the flag is on, the actual configuration happens at the cost template level. Navigate to Project management and accounting, then Setup, then Estimates, then Cost templates, and open the relevant cost line. On the General tab, set Cost to complete method to Total forecast minus actual, and set Use forecast amount for revenue recognition to Yes. That combination tells the system to calculate cost-to-complete from the forecast rather than from a manually entered total, and to use that forecast figure specifically for revenue recognition math rather than treating it as informational only.

A second setting matters just as much and gets missed more often. Under Project management and accounting parameters, on the Revenue recognition tab, set Allow posting when cost to complete is less than the check value to Warning rather than leaving it at its default blocking behavior. Because actual costs can legitimately run ahead of an unrevised forecast under this method, a hard block here will stop legitimate period-end postings. Warning mode lets the transaction post while flagging it for review, which is the right tradeoff once you have accepted that overruns are supposed to show up as variance rather than as a posting error.

Two scope limitations are worth knowing before you commit to a rollout. The feature currently supports completion methods based on cost amount or quantity. Projects using an effort or hours-based completion method were not part of the documented scope as of GA, so confirm your contract lines’ estimate methods before assuming this applies portfolio-wide. And because configuration lives at the cost template and cost line level, a project stitched together from multiple templates, some forecast-based and some not, can end up with genuinely inconsistent recognition behavior across its own cost lines. That is worth an audit of your template library before flipping the switch broadly, not something to discover during a client’s fiscal year-end.

Rollout Considerations for Projects Already in Flight

Project accounting team reviewing budget versus actual cost trends in a meeting room

Microsoft’s own documentation does not spell out how this interacts with periods that have already posted revenue under the old EAC-based calculation, and that ambiguity is reason enough for caution rather than assumption. Treat this as a forward-looking configuration change. Apply it to new fixed-price projects and to contract lines that have not yet posted revenue, and validate the behavior in a sandbox environment against a handful of representative project types before touching anything live in production. Run the same project through both calculation methods side by side for a period or two if your close calendar allows it. Seeing the actual delta between EAC-based and cost-estimate-based percentages on real data will tell you more about whether this is the right default for your portfolio than any amount of reading the release notes.

There is also a governance conversation worth having before this becomes the standing configuration. Cost estimate revenue recognition trades EAC’s volatility for a different kind of risk: a bad forecast set at project kickoff now drives revenue recognition for the life of the contract unless someone deliberately revises the baseline. That is a feature, not a bug, for teams whose real problem was noisy month-to-month recognition. It is a liability for teams whose original estimates were never particularly reliable to begin with. Stabilizing a number does not make it more accurate. It just makes it stop moving, which can look like accuracy without being it.

At Routeget, we have started building a review of this setting into 2026 release wave 1 upgrade assessments for clients running Project Operations at scale, rather than leaving it as an optional toggle someone discovers by accident. The fixed-price portfolios most exposed to EAC-driven revenue swings tend to be the ones with the tightest client reporting requirements, which means they stand to gain the most from a stable baseline and have the least tolerance for getting the transition wrong. Pilot it deliberately, audit your cost templates before rollout, and keep the forecast-accuracy conversation alive even after the volatility disappears from your month-end close.

#ProjectOperations #RevenueRecognition #CostEstimateMethod #ProjectAccounting #FinancialClose #EnterpriseERP

Your Dataverse Customer-Managed Key May Have Silently Reverted in January

IT security professional reviewing a data encryption key management dashboard in a modern operations center

A compliance team preparing for a SOC 2 renewal pulls up its Power Platform admin center to confirm what it has told auditors for two years running: that its Dataverse customer-managed key, stored in the organization’s own Azure Key Vault, keeps its data encrypted under keys Microsoft cannot touch without their say. The screen says something different. The environment shows “Microsoft Managed key.” Nobody remembers approving that change, because nobody did. It happened automatically, on a date that passed eight months earlier, and the only trace of it is a single line in the environment’s admin history.

This is not a hypothetical. Microsoft retired its original bring-your-own-key (BYOK) encryption feature for Dataverse on a hard schedule: new production environments could no longer be enrolled in BYOK after June 1, 2025, and any environment still running on BYOK that had not completed migration to the newer customer-managed key (CMK) model by January 6, 2026 reverted automatically to a Microsoft-managed key. Encryption continued without interruption, so nothing broke. That is precisely the problem. An organization can lose the control it has been representing to regulators, customers, and its own board, and the system will not tell anyone unless someone goes looking.

For CIOs and IT Directors who treat encryption key ownership as a checkbox on a compliance questionnaire rather than a control that needs periodic verification, this is worth an afternoon of attention right now.

Why a Dataverse customer-managed key was worth having in the first place

Customer-managed key was never about making Dataverse more secure in a technical sense. Microsoft-managed keys use the same underlying encryption standards either way. What CMK provides is contractual and operational leverage: the ability to revoke Microsoft’s access to the underlying data by disabling a key in Azure Key Vault, independent of any support ticket or service request. For organizations in regulated industries, defense-adjacent supply chains, or jurisdictions with data sovereignty requirements, that revocation capability is often the specific control a customer contract, a government agency, or an internal risk committee asked for by name.

That is also why the BYOK-to-CMK transition matters more than a typical feature deprecation. A lapsed migration does not remove a nice-to-have. It quietly removes the exact control that a Business Associate Agreement, a defense contract, or a data processing addendum may reference. If that control disappeared in January and the organization’s compliance narrative has not been updated since, the gap is not a technical debt item. It is a misrepresentation risk sitting in a vendor security questionnaire that was answered honestly a year ago and has not been true since.

Checking whether this happened to you

The check itself takes minutes. In the Power Platform admin center, under Security, then Data and Privacy, then Customer-managed encryption key, any enterprise policy still listed will show its current status against each enrolled environment. An environment that reverted during the January cutoff will show “Microsoft Managed key” rather than “Encrypted.” The same information is visible at the environment level: open the environment’s history and search for “Update Customer Managed Key,” which will show the reversion event and its timestamp if one occurred.

Organizations that never adopted BYOK or CMK in the first place have nothing to check here, since they were never claiming otherwise. The exposure is specific to organizations that adopted BYOK, told someone about it, and then let the migration window close without follow-through, which is a more common outcome than it should be given how disruptive CMK migrations used to be to plan around.

Compliance officer and IT director reviewing a security audit and cloud governance dashboard in a meeting room

What changed that makes CMK worth reconsidering now

The reason many organizations dragged their feet on migrating from BYOK to CMK in the first place was operational risk, not indifference. Applying a customer-managed key used to mean an environment going fully offline for the duration of encryption, and if a Key Vault permission got revoked by accident, whether through an access review, a policy change, or a departing employee’s role cleanup, the environment locked and stayed locked until Microsoft support intervened. For an IT Director who has lived through that kind of outage once, avoiding a second one is a rational, if costly, choice.

Microsoft’s updates to CMK over the past year address both of those specific failure modes. Core Dataverse services now come back online once the primary encryption pass finishes, with secondary services continuing to encrypt in the background under an “Encrypting – online” status, so the outage window during initial enrollment is shorter than it used to be. More significantly, environment administrators can now restore access themselves once a revoked Key Vault permission is fixed, rather than opening a support case and waiting. That single change removes the scenario that made a lot of security teams nervous about CMK in the first place: an internal mistake in Azure RBAC no longer means the environment stays dark until Microsoft gets involved.

CMK has also expanded into GCC High, giving U.S. government entities and defense contractors the same encryption-key control in a sovereign cloud environment that commercial customers have had, and Azure Key Vault Managed HSM support for Dataverse has moved into preview, which will matter to organizations whose compliance framework specifically calls for hardware security module protection rather than software-protected keys.

Solution architect configuring cloud key vault access controls at a workstation

The coverage gap that still needs to be in the compliance narrative

None of this means CMK covers everything, and any accurate representation to an auditor or a customer needs to say so. Applying a customer-managed key to a Managed Environment encrypts Dataverse data and most of the Dynamics 365 apps built on it, but Power Automate flow data tied to that environment continues to be encrypted with a Microsoft-managed key regardless of the environment’s CMK status. Connector connection settings, environment configuration metadata, and a handful of other categories Microsoft classifies separately are also excluded. A CIO who tells a customer “our Dataverse environment is fully under customer-managed key” is accurate about the data that matters most in nearly every case, but a security questionnaire that asks about encryption coverage across the entire Power Platform estate deserves the more precise answer, not the simplified one.

What this means for planning the next quarter

For organizations that discover a silent reversion, the fix is a re-enrollment, not a support escalation: create or reuse an Azure Key Vault with soft-delete and purge protection enabled, generate or reuse an RSA key, stand up an enterprise policy, and add the environment back in through the admin center, with the expectation that core encryption completes within about four days and the environment stays reachable for most of that window under current behavior. Licensing needs a second look too, since CMK still requires a qualifying Microsoft 365 or Office 365 compliance-tier license (the E5, A5, F5, or G5 compliance and information protection SKUs) on top of the Managed Environments entitlement that comes with standard Power Platform and Dynamics 365 licensing.

For organizations that have been putting off CMK adoption entirely, the calculus has genuinely shifted. The two operational objections that used to show up in every internal debate, extended downtime and support-dependent recovery from an access mistake, have both been addressed directly. What has not changed is the governance discipline CMK requires: separating the person who administers the Key Vault from the person who administers the Power Platform environment, setting expiration alerts on the key well before it lapses, and documenting the enterprise policy and resource IDs somewhere that survives staff turnover. CMK gives an organization real control over its own encryption keys. It also gives that same organization the ability to lock itself out if that control is managed carelessly, and the discipline required to avoid that outcome has not gotten any less important just because the recovery path got shorter.

Routeget Technologies has walked several clients through exactly this kind of CMK re-enrollment after a lapsed migration, and the pattern is consistent: the technical fix is straightforward once someone notices the gap, and the harder part is almost always internal, tracking down who last touched the enterprise policy and confirming what was actually represented to auditors or customers in the meantime. That reconciliation work is worth doing before the next audit cycle asks the question first.

#Dataverse #CustomerManagedKey #EncryptionKeyManagement #DataSovereignty #ComplianceRisk #CloudGovernance

What Actually Breaks First in a Power Apps Code Apps Rollout

Developer reviewing a Power Apps code app in a code editor next to a web application preview

A team at a mid-market manufacturer spent three weeks building their first Power Apps code app: a React front end wired to Dataverse through the generated TypeScript services, styled with Fluent UI, running clean in local development. The day they pushed it to their first pilot users, the app loaded, authenticated through Microsoft Entra ID without a single line of auth code, and then silently failed to render three of its five widgets. The culprit wasn’t a bug in their code. It was a tenant-wide Content Security Policy that Microsoft had already turned on weeks before their app was even scaffolded, quietly blocking every request to a domain outside the Power Apps allowlist. Nobody on the project had heard of it, because nobody had read the message center post that announced it.

That kind of surprise is a fair preview of what a Power Apps code apps rollout actually looks like right now. Since February 5, 2026, Power Apps code apps have been generally available, letting developers build full front-end web applications in React or Vue inside a code-first IDE like Visual Studio Code, then run and host those same apps inside the managed Power Platform, with the platform handling authentication, connector access, and lifecycle management underneath. For architects who have spent years explaining why a canvas app can’t do what a pro-code team needs, this closes a real gap. GA status makes it easy to underestimate three things that behave nothing like a typical canvas app rollout, though: a content security policy that was already enforcing before most organizations had even piloted the feature, a licensing model built around Premium seats rather than the cheaper per-app plan many teams still lean on for canvas apps, and an ALM story that looks familiar until you notice which pieces are missing.

The CLI Workflow, In Practice

A code apps project starts from the pac code command group in the Power Platform CLI rather than from the maker portal. After scaffolding a project (Microsoft’s own quickstart pulls a Vite template via degit), pac code init --displayname "App Name" registers the app against an environment and writes a power.config.json file tying the local project to that registration. Adding a Dataverse table as a data source looks like this:

pac code add-data-source \
  -a "shared_commondataserviceforapps" \
  -c "<connection-id>" \
  -t "accounts"

That command handles the unglamorous but genuinely useful part of the job: it generates a typed service class in ./generated/services/, so the resulting TypeScript reads like AccountsService.getall() and AccountsService.create({ name: "Contoso Ltd" }) rather than hand-rolled HTTP calls against the Dataverse Web API. The connection itself, though, has to already exist in make.powerapps.com. The CLI wires up access to an existing connector connection; it does not create one. That means whoever owns the pilot needs a connections strategy in place before a developer ever opens an editor. Once the app is built, npm run build followed by pac code push ships it to the platform, where it inherits the same sharing limits, quarantine behavior, and Conditional Access controls that already govern canvas apps in that environment.

That inheritance is the real point of running code apps inside Power Platform instead of standing up a bespoke Azure Static Web App: Data Loss Prevention policies still apply at runtime, tenant isolation and Azure B2B rules still apply, and the app shows up in Power Platform Monitor for health telemetry the same way any other maker-built app would. None of that governance has to be rebuilt by hand.

Developer working on a code apps project across two monitors showing a code editor and a web application preview

Where the CSP Wall Actually Sits

Microsoft began enforcing a strict Content Security Policy against code apps in two stages: introduction on January 26, 2026, and full enforcement on January 30, 2026, communicated through message center post MC1218747. Past that date, any request a code app makes to a domain outside the Power Apps allowlist gets blocked by default, silently, at the browser level. The app itself keeps running. It’s the fetch calls to a third-party API, the image tags pointed at an external CDN, or a web font loaded from outside Microsoft’s own domains that quietly stop resolving, which is exactly the kind of failure that reads like a rendering bug rather than a policy block until someone actually opens the browser console.

The fix isn’t difficult, but it has to happen before a real rollout rather than after users start filing tickets. Microsoft’s own guidance describes a five-step sequence: temporarily disable the “Enforce content security policy” setting in the Power Platform admin center, turn on CSP reporting instead, exercise the app enough to surface every external domain it actually calls, add those domains to the allowlist, and only then re-enable enforcement. Skip the reporting step and jump straight to a hand-built allowlist, and a team ends up chasing one broken image or one failed API call at a time, across three environments, for weeks.

The License Model Nobody Priced In

The other assumption worth checking before a pilot expands past a handful of users is licensing. Microsoft’s documentation is specific on this point: end users running a code app need a Power Apps Premium license, full stop. That catches teams who assumed code apps would ride along on whatever licensing already covers their canvas apps, particularly organizations that still lean on the per-app plan for cost control. That plan is in the middle of its own wind-down: as of January 2, 2026, it’s no longer available for purchase by new customers, though existing Enterprise Agreement and Cloud Solution Provider customers can keep renewing it under current terms, and MPSA customers get a 60-day migration window after their agreement ends. None of that grandfathering helps a team piloting code apps for the first time this year, because a per-app license was never going to cover a code app to begin with. The practical move for an architect scoping a rollout is to put the Premium requirement into the business case during the first conversation with finance, not to let it surface when the pilot tries to onboard its fifteenth user.

What ALM Actually Covers, and What It Doesn’t

Solution architects evaluating code apps for a broader rollout should also be honest about what doesn’t carry over from the rest of the Power Platform toolbox. Native Power Platform Git integration doesn’t support code apps today, so a team can’t rely on the same solution-based source control workflow it might use for a model-driven app. The practical workaround is treating the code app’s own repository as the system of record and running a standard CI pipeline against it, GitHub Actions calling pac code push after a build step is a common pattern, rather than expecting Dataverse solutions to manage the app’s lifecycle end to end. Code apps also can’t run offline, aren’t supported in the Power Apps app for Windows, don’t support Secure Implicit Connections, and can’t be embedded inside other app types except through a Power BI Visual. For a field service scenario that genuinely needs offline capability, or a mobile-first workflow, this rules code apps out entirely. They’re built for client-side, standalone, always-connected line-of-business scenarios, and treating them as a drop-in replacement for every canvas app on a roadmap produces a project that fights the platform instead of one that benefits from what GA actually delivered.

Solution architects reviewing a governance and security policy dashboard in a meeting room

Planning a Power Apps Code Apps Rollout

None of this argues against adopting code apps. It argues for sequencing the rollout the way any new application platform deserves, rather than the way a low-code feature update usually gets treated. Before the first pilot ships to real users, confirm the environment has code apps enabled deliberately, through Settings, Product, Features, rather than left to whichever admin happened to click through a prompt. Run the CSP disable-report-allowlist-reenable cycle against the actual pilot app, not a hello-world sample that calls no external services and tells an architect nothing useful. Get Premium licensing into the cost conversation before the user list grows past the pilot group, not after. And decide early which category of app actually belongs here: a case-management tool for an internal finance team, wired to Dataverse and a couple of line-of-business connectors, is a strong fit. A field technician’s offline inspection app is not, regardless of how appealing the React tooling looks to the team building it.

Code apps are a genuine expansion of what Power Platform can host, and for organizations with pro-code developers sitting next to citizen developers, they finally give both groups a shared platform instead of two disconnected ones. Getting there without a production incident, though, means treating the CSP policy, the licensing model, and the ALM gaps as part of the architecture decision, not as details to sort out after the first app is already live. Routeget’s team has walked several clients through exactly this sequencing on early code apps pilots, and the pattern holds: the rollouts that go smoothly are the ones where governance and licensing get scoped in the same week as the first line of code, not after the first support ticket comes in.

#PowerAppsCodeApps #PowerPlatformGovernance #PowerAppsLicensing #ContentSecurityPolicy #PowerPlatformALM #EnterpriseAppDev

The Power BI Premium Retirement Has a Fabric Capacity Migration Trap Most Budgets Miss

Finance and IT leader reviewing a cloud capacity and cost analytics dashboard, representing the Power BI Premium to Fabric capacity migration decision

Somewhere in the last few months, a Power BI Premium renewal notice landed on a procurement desk with a number that didn’t match last year’s invoice, and nobody could immediately explain why. That scene is playing out across a lot of finance and IT organizations right now, because Power BI Premium’s per-capacity SKUs (the familiar P1 through P5 tiers) are being phased out in favor of Microsoft Fabric capacity, and a Fabric capacity migration for many enterprises is landing at the exact moment their Enterprise Agreement comes up for renewal. Non-EA customers lost the ability to renew Premium capacity back in January 2025. EA holders have had more breathing room, but only until their current agreement term ends, and a wave of three-year EAs signed in 2023 are hitting that wall throughout 2026.

The mechanics of the transition get covered reasonably well in Microsoft’s own migration documentation: reassign workspaces to a Fabric F-SKU, validate refreshes and gateways, decommission the old capacity. What gets far less attention, and what has already caught more than one IT Director off guard mid-negotiation, is a licensing detail buried a few layers into the SKU comparison: not every Fabric capacity size preserves the free-viewer access that Power BI Premium customers have taken for granted for years.

Why F64 Is the Number That Actually Matters

Under Power BI Premium, any user with the Free license could view content in a workspace backed by Premium capacity, so long as they had a Viewer role. That was one of Premium’s core value propositions for large organizations: a single capacity purchase covered report consumption for hundreds or thousands of employees without individual Pro licenses.

Finance and IT leader reviewing a cloud capacity and cost analytics dashboard, representing the Power BI Premium to Fabric capacity migration decision

Fabric capacity does not carry that benefit uniformly across its SKU range. Free-user viewing only returns at F64 and above. Anything from F2 through F32, the sizes that map to smaller or mid-sized Premium deployments on paper, requires every single viewer to hold a Power BI Pro or Premium Per User license. For an organization whose consumption metrics suggest a P1-equivalent capacity would be plenty, the naive read-across is F64 anyway (Microsoft’s own sizing guidance maps P1 to F64), so this often isn’t a problem for P1 customers specifically. The real exposure shows up for organizations that assumed they could right-size downward, based on actual utilization data, into an F32 or smaller footprint to save on the recurring Fabric bill, only to discover that doing so would require issuing several hundred new Pro licenses to preserve the same viewer population that costs nothing today.

That’s not a hypothetical. It’s the kind of number that shows up in a board deck as a line item nobody budgeted for, and it’s precisely the sort of decision that needs to be modeled before a renewal date forces a choice, not after.

The Real Timeline Pressure

Microsoft’s transition isn’t open-ended once a Premium term lapses. There’s a 30-day grace period after a P-SKU subscription ends, during which capacity keeps functioning while a migration gets finalized. After day 30, access starts getting throttled, meaning interactive operations slow down or get delayed. Past day 90, every operation against that capacity gets rejected outright. The underlying data isn’t deleted, but it becomes fully inaccessible until either the migration completes or the capacity is retired for good.

For a CIO or IT Director, the practical implication is that “we’ll deal with the Fabric migration next quarter” is not a safe posture once an EA renewal date is visible on the calendar. The sequencing matters too: the recommended path is to provision the new F-SKU capacity, reassign workspaces to it, validate that refreshes and reports behave correctly, and only then cancel the old Premium subscription, because that cancellation doesn’t happen automatically and the two capacities can run in parallel briefly during validation. Treating this as a same-week swap invites exactly the kind of outage that turns a licensing decision into an incident review.

Sizing the Fabric Capacity Migration Instead of Guessing at It

Solution architect reviewing a stepped bar chart representing Fabric capacity sizing tiers on a workstation monitor

The good news is that Microsoft doesn’t leave the sizing decision to intuition. The Fabric Capacity Metrics app, which connects to a tenant’s actual consumption history, is the mechanism most consulting teams now use to baseline 30 to 45 days of real Premium usage before committing to an F-SKU size. Organizations with sustained utilization near the ceiling of their current capacity generally need an equivalent or larger Fabric SKU to avoid throttling. Organizations with long stretches of low activity, evenings, weekends, month-end lulls followed by spikes, are often better served by a smaller capacity paired with Fabric’s pause and resume functionality, something Premium never offered. Pausing a capacity during genuinely idle hours stops billing entirely, which is a real lever for reducing the annual spend rather than just shifting it from a Microsoft 365 line item to an Azure one.

That said, the free-viewer threshold at F64 has to be weighed against pure utilization math. A tenant whose usage data suggests F32 is technically sufficient may still come out ahead financially by sizing up to F64 and avoiding a mass Pro license rollout, and that comparison is specific enough to the organization’s own viewer count and existing Pro license penetration that it needs to be run as an actual cost model, not assumed either way.

What Else Changes Beyond the Bill

A few other differences are worth putting in front of a decision-maker evaluating this migration, because they shape both cost and risk. Fabric capacity is billed through Azure, on a pay-as-you-go or reserved basis, rather than through the Microsoft 365 commitment model Premium customers are used to, which means the invoice shows up in a different place and often gets reviewed by a different team. Capacity-level settings, things like semantic model memory limits or custom workload configurations, don’t carry over automatically during migration and need to be recreated on the new capacity, so a lift-and-shift assumption can leave gaps in governance that only surface later. And for organizations considering a cross-region move as part of the migration, perhaps to consolidate capacity somewhere with better Azure pricing, large-format semantic models and other Fabric items generally don’t survive that move intact; they need to be backed up and recreated, which introduces real downtime that a same-region migration wouldn’t require. For most organizations, the operational cost of that rebuild outweighs whatever regional pricing delta prompted the idea in the first place.

Getting Ahead of the Renewal Date

None of this argues against moving to Fabric capacity. The pause and resume billing, the built-in Power BI Embedded rights, the tighter Azure governance integration through managed private endpoints and RBAC, these are genuine improvements over what Premium offered, and the migration itself is generally low-risk when it stays within the same tenant and region. The argument is against treating this as a routine renewal to be handled by whoever owns the Microsoft relationship without IT and finance jointly reviewing the sizing math first.

The organizations getting this right are starting the Capacity Metrics baseline well before their EA renewal conversation, running the free-viewer cost comparison as an actual spreadsheet rather than an assumption, and building the migration into a maintenance window rather than a renewal-week scramble. We’ve walked several clients at Routeget Technologies through exactly this exercise this year, and the pattern holds: the technical migration is rarely the hard part. The licensing model change underneath it is what catches finance teams by surprise, and it’s avoidable with about a month of preparation.

If your Power BI Premium renewal or EA term ends anytime in the next twelve months, that preparation should be starting now, not when the notice arrives.

#PowerBI #MicrosoftFabric #FabricCapacityMigration #ITBudgetPlanning #DataAnalyticsStrategy #CloudCostManagement

Closing the Direct Inward Dial Overflow Gap in Dynamics 365 Contact Center

Contact center operations manager reviewing a call routing and queue visualization dashboard in a modern control room

A contact center administrator spends a sprint tuning overflow rules for the sales voice queue: wait-time thresholds calibrated against real call volume, a callback offer instead of a hold queue during lunch-hour spikes, a fallback voicemail script that does not sound like an apology. Test calls placed through the published support number behave exactly as configured. Then a prospect who picked up a business card at a trade show dials a sales representative’s direct number after hours. The phone rings four times and drops into a generic voicemail greeting nobody has touched since the line was provisioned, because nothing in the Contact Center overflow configuration ever saw that call. It never passed through a queue at all.

This is the direct inward dial overflow problem, and it shows up in more Dynamics 365 Customer Engagement implementations than most solution architects expect. Configuring overflow on a voice queue protects the calls that arrive through that queue. It does nothing for a call that lands on an individual representative’s assigned number, which is a distinct and fairly ordinary path into the organization that unified routing was never built to see.

Why Overflow Rules Never See These Calls

Unified routing’s overflow handling evaluates work items at two points. Before a call or conversation is queued, the system checks whether the queue is outside operating hours, whether it already holds more open items than a configured limit, and, for voice specifically, whether the predicted wait time exceeds a threshold set anywhere from thirty seconds to sixty minutes. After a work item has been queued, a second check tracks how long it has actually waited, from one minute up to two days depending on channel, and applies whatever action an administrator attached: transfer to a different queue, a callback offer, voicemail, or an external number.

All of that logic runs against work items that entered the routing pipeline through a workstream’s route-to-queue rules. A direct inward dial call to a representative’s personal number never enters that pipeline. It rings the representative’s device the way any phone call would, which is precisely the convenience the number is meant to offer, and it means the overflow conditions above are never evaluated because there is no queued work item to evaluate. Whatever happens when the call goes unanswered is whatever the telephony carrier or device does by default, not anything Dynamics 365 governs. This is not the only blind spot of its kind: work items that land in a fallback queue because of a classification error or an unmatched routing rule bypass overflow handling too, for the same reason. Overflow protection only applies to the specific path it was designed to watch.

Configuring Direct Inward Dial Overflow with Conversation Orchestration

Conversation Orchestration, still in preview as of this writing, is the first native mechanism that gives administrators a way to close this gap rather than work around it with a separate telephony configuration. It replaces the traditional condition-action rule editor with playbooks authored in guided natural language, which a language model then converts into a structured runtime policy. Each playbook has four parts: the queues it applies to, the trigger event that starts evaluation, up to ten conditions built from context variables such as customer tier or account type, and the action taken when those conditions are met.

Among the available triggers is one built specifically for this scenario: a direct inward dialed call received, paired with a condition checking whether a representative is actually available. When that condition is met, the playbook can route the call to voicemail, transfer it to an alternative queue, or redirect it into a callback queue instead of leaving it to ring out. It is the same category of protection unified routing has offered queued calls for years, finally applied to a path that queue-based overflow rules cannot structurally reach.

Before building a playbook, a few prerequisites need to be in place: unified routing enabled, at least one queue and voice or messaging workstream already configured, an active channel, and a System Administrator or Omnichannel Administrator doing the configuration. Organizations on a pay-as-you-go plan also need an Azure subscription with consumption billing set up, since orchestration is metered separately from standard licensing.

Building the Playbook: A Concrete Example

Solution architect at a dual-monitor workstation reviewing an abstract call-routing logic diagram

Consider an enterprise sales team where several senior representatives have published direct numbers on their email signatures and LinkedIn profiles. The architect’s goal is not to eliminate direct dialing, which the team values precisely because it skips the queue, but to make sure a missed call does not simply vanish. The playbook scopes itself to the queues associated with those representatives, sets the trigger to a direct inward dialed call received, and adds a condition for representative availability. From there the logic branches: an account flagged as top-tier gets transferred live into a staffed key-accounts queue rather than dropped to voicemail, while every other caller gets a voicemail action paired with a script that points to the published support line and a realistic callback window, so the prospect from the trade show has somewhere else to go immediately.

Publishing enforces a few constraints worth planning around. Only one active playbook can cover a given queue and scenario at a time, so a second attempt to publish a conflicting DID overflow policy for the same queue fails with an explicit error rather than silently overriding the first. A draft playbook is fully editable, but once active, changes require a full save-and-publish cycle rather than a quiet in-place edit, a reasonable guardrail against someone adjusting live call-handling behavior without realizing it took effect immediately.

What Breaks in Practice, and How to Test For It

The natural-language authoring model is convenient, but Microsoft’s own documentation is candid that the conversion from plain-language intent to runtime logic will not always capture what the administrator meant, and that deviations only surface once the policy is running against real conversations. That makes a habit of placing genuine test calls after every publish, not just re-reading the playbook description, a non-negotiable part of the rollout rather than an optional nicety. A policy that reads correctly in the authoring pane can still behave differently once it is evaluating live availability data.

Playbooks are also event-driven rather than evaluated once, which changes how architects should think about multiple active policies on the same queue. A dynamic-prioritization playbook and a DID overflow playbook can both run simultaneously, firing independently as different conditions become true over the life of a single call, so priority might escalate at the thirty-second mark from one policy while an overflow action triggers five seconds later from a second policy reacting to every representative signing out. Treating these as a single ruleset, the way legacy overflow configuration works, produces confusing results; they need to be tested as independent, potentially overlapping processes.

Migration between environments deserves its own checklist. Playbooks move through standard Power Platform solution export and import, using the underlying prompt table, but only cleanly if every queue, context variable, and dependent component they reference already exists in the destination environment first. Importing a playbook ahead of its dependencies does not fail cleanly; it leaves broken references that surface later as orchestration silently not firing, a far more frustrating way to discover a missing prerequisite than an outright import error.

One more consideration belongs on the pre-production checklist rather than after go-live: because this feature touches individual representatives’ direct lines and depends on monitoring their real-time availability, Microsoft’s guidance is explicit that organizations must notify representatives their communications may be monitored, secure customer consent where required, and never use the orchestration data to inform employment decisions such as compensation or performance reviews. That is a legal and HR conversation, not just a configuration one, and it belongs before go-live rather than after someone asks what the availability data is being used for.

It is worth setting this next to its closest sibling: automatic handling of waiting conversations when a queue closes or becomes unstaffed, which reached general availability in mid-2026 as a standard queue capability rather than a preview playbook. Between the two, most deployments can now cover both halves of the same failure mode, a customer left with no available representative, one through native queue configuration and the other through a playbook that still carries preview caveats.

Where This Leaves Contact Center Architects

None of this makes Conversation Orchestration as production-hardened as a decade-old queue overflow rule set, and Microsoft is not claiming otherwise. What it does confirm is that the direct inward dial gap is real, it predates this feature by years, and most Contact Center deployments have never actually been audited against it. A reasonable next step does not require waiting for general availability. It requires pulling a list of every representative with a published or easily discoverable direct number and asking a blunt question: what actually happens on that line right now if nobody answers. For a lot of organizations, the honest answer is nothing configured, nothing tested, and nothing anyone would want a customer to experience. Routeget’s customer engagement practice has walked several active Contact Center rollouts through exactly this kind of gap analysis, and the pattern holds regardless of company size: the queues get the attention during implementation, and the direct lines get forgotten until a customer falls through one.

#ContactCenter #UnifiedRouting #ConversationOrchestration #DirectInwardDial #OmnichannelCX #DynamicsCustomerService

Business Central Assumes Infinite Capacity. Your Shop Floor Doesn’t.

Manufacturing operations manager reviewing a production scheduling timeline display in a plant office

A plant manager pulls up a production order in Dynamics 365 Business Central on a Tuesday morning and finds the scheduled start date sitting three days in the past. Nothing is wrong with the data. Business Central’s scheduling engine did exactly what it was designed to do: it calculated lead times backward from a promised ship date, ignored what else was already booked on that work center, and produced a plan that assumes the shop floor has unlimited hours to give. The manager now has two choices. Spend the next hour manually rearranging operations by eye, or accept a schedule that was never realistic in the first place. Multiply that by every work center, every week, and the real cost of Business Central capacity planning becomes visible: not a software defect, but a design decision that a lot of growing manufacturers eventually outgrow.

This is not a knock on Business Central as an ERP platform. For finance, inventory, and general operations, it does what a mid-market system should do. But its native production scheduling was built around a simpler assumption than most discrete or process manufacturers actually operate under, and understanding exactly where that assumption breaks is the first step toward deciding whether to live with it, work around it, or bring in something purpose-built to close the gap.

How Business Central Capacity Planning Works Today

Business Central schedules production orders using routing times, work center and machine center calendars, and either a forward or backward scheduling direction depending on whether the driving date is the order start or the promised delivery date. By default, this runs as infinite capacity scheduling: the engine calculates when an operation should happen based on lead times and sequencing, without checking whether the work center is already booked during that window. It is fast, and for a single order in isolation it produces a clean answer. The trouble starts when dozens of orders compete for the same handful of machines.

Business Central does offer a step toward realism through capacity constrained resources. A planner can register a work center or machine center as capacity constrained, which shifts scheduling to account for existing load rather than assuming the resource is always free. Manufacturers can also open the load matrix on a work center card and view capacity against load by day, week, or month, in either a net-change or cumulative view, which is genuinely useful for spotting a bottleneck before it becomes a missed ship date. What this setup does not do is resolve the conflict automatically. It surfaces the overload and leaves the planner to fix it, one operation at a time, inside a grid rather than a visual timeline.

That distinction, between a system that flags a problem and one that helps you solve it, is where the native tool set runs out of runway for a lot of manufacturing operations.

Manufacturing operations manager reviewing a production scheduling timeline display in a plant office

Where the Gap Actually Shows Up

The practical failure modes tend to look the same across different manufacturers, regardless of industry. Sequencing decisions, such as which of three competing orders gets the CNC machine first on Thursday afternoon, are left entirely to the planner’s judgment rather than being informed by setup time, tooling changeovers, or downstream dependencies the system already has data on. Machine breakdowns, absenteeism, and rush orders are realities that the schedule has no mechanism to absorb once it has been generated, so a single disruption cascades into an afternoon of manual replanning rather than a quick recalculation. And because the standard interface presents schedule data as rows in a list rather than bars on a timeline, a planner cannot see at a glance that moving one operation two hours later would clear an overload three operations downstream. Every one of these is solvable inside Business Central’s data model. None of them is solvable inside its native screens without a meaningful amount of planner effort and institutional memory about which orders always cause trouble.

For a small job shop running a handful of work centers, this is manageable with discipline and a good planner. For an operation running double-digit work centers with mixed routings, alternate machines, and customers who expect accurate ship dates, the manual overhead compounds fast, and it tends to land on the same one or two people who become a single point of failure for the entire schedule.

What a Visual Scheduling Layer Adds

This is the gap that a category of AppSource-listed manufacturing extensions has grown up to fill, and it is worth understanding as two distinct tiers rather than one undifferentiated feature.

The first tier is visual scheduling: a Gantt-style planning board that sits on top of Business Central’s existing production order and routing data, showing operations as draggable bars against work centers and machine centers rather than as list rows. NETRONIC’s Visual Production Scheduler, now part of Boyum IT following its 2024 acquisition, is the best-known example of this approach. Moving a bar reschedules the operation and writes the change back to the underlying production order immediately, with capacity histograms showing utilization by day or week so a planner can see an overload forming before committing to a change. This does not automate the scheduling decision. It makes the decision visible and fast to execute, which for many operations is the actual bottleneck rather than the underlying math.

Production planner reviewing a visual scheduling board with machine and work center bookings at a workstation

The second tier adds an automated finite capacity engine on top of that visualization. Insight Works’ MxAPS and NETRONIC’s Visual Advanced Production Scheduler both fall into this category, generating a schedule that accounts for machine and labor availability, tooling constraints, and material readiness without manual sequencing, and allowing planners to run multiple what-if scenarios before publishing one to the live schedule. This tier is a genuinely different proposition than visual scheduling alone. It is closer to the finite capacity planning Microsoft already offers natively in Supply Chain Management for enterprise customers, delivered instead as a third-party layer for the Business Central side of the product family, which does not include an equivalent built-in optimizer.

Neither tier is free, and neither is a drop-in decision. MxAPS, for example, requires the Business Central Premium edition, which itself carries a per-user cost difference from Essentials that should be part of the licensing conversation before a manufacturing operations leader gets attached to a specific tool. The right question is not which named product to buy. It is which tier of capability the operation actually needs, because a company struggling mainly with schedule visibility and manual drag-and-drop effort may get most of the value from the first tier at a fraction of the cost and implementation complexity of the second.

Deciding Whether This Is Worth Solving

Before budgeting for either tier, it is worth running a short internal audit. How many hours per week does a planner spend manually rearranging the schedule after it is first generated, and what is that time worth against a subscription cost measured in the low thousands per year. How often does a customer-facing ship date change because of a scheduling conflict that only became visible after the fact, rather than being caught in advance. And how much of the current process depends on one person’s memory of which machines, operators, or tooling combinations tend to cause problems, since that is institutional risk regardless of what software is in place.

If the answer to those questions points to real, recurring cost, a visual scheduling layer is one of the more straightforward manufacturing investments to justify, because the software sits directly on top of data Business Central already has rather than requiring a new implementation project. If the disruption is occasional and a disciplined planner is already managing it well with the load matrix and capacity constrained resources, it may be entirely reasonable to hold off and revisit the question as order volume or work center count grows.

Routeget Technologies has walked manufacturing clients through exactly this evaluation, weighing native capability against the two tiers of scheduling extensions before a licensing dollar is spent, and the pattern holds across most engagements: the decision is rarely about which vendor has the flashiest demo. It is about matching the tier of automation to the actual planning problem on the shop floor, and being honest about how much of that problem discipline alone can solve versus how much genuinely requires a different tool.

#BusinessCentral #ManufacturingScheduling #ProductionPlanning #ERPCapacityPlanning #DiscreteManufacturing #DigitalTransformation