September 2026

Power Apps Offline Profiles Just Got Easier to Build, Not Easier to Govern

Field service technician using a mobile tablet app in a low-connectivity industrial environment, representing Power Apps offline mode for field workers

A regional field service operation gave its dispatch team the green light to build a canvas app for technicians working in cellular dead zones: rural service calls, basement mechanical rooms, warehouses with concrete walls that killed every signal. The maker who built it, an operations analyst with no formal development background, had the app running offline in an afternoon. No ticket to IT, no admin center request, no waiting on a platform team’s sprint capacity. Three weeks later, a technician’s equipment inspection notes from a Friday afternoon call never made it into Dataverse. The app had been minimized on his phone all weekend while he checked email and texted his dispatcher, and Power Apps only syncs when it is actually running in the foreground. The data was not corrupted or lost outright, but it sat unsynced long enough that a compliance audit flagged a two-day gap in a safety inspection record that mattered.

That scenario is becoming more common, and it traces directly back to a change in how Power Apps offline profiles get created in the first place, a shift most IT organizations have not caught up to yet.

Power Apps Offline Profiles Move to Maker Studio

Until December 2025, configuring an offline profile for a Dataverse-backed canvas app meant a trip to the Power Platform admin center. A system administrator or system customizer had to define which tables synced, set filters to control data volume, and manage relationships, all through an admin-only surface that kept offline configuration inside IT’s field of view almost by accident. That friction was never framed as a governance control, but it functioned like one: nothing went offline without someone with elevated permissions touching it first.

Microsoft’s 2025 release wave 1 changes removed that checkpoint. Offline profile creation moved directly into Power Apps Studio, reaching general availability on December 12, 2025. A maker building a canvas app can now toggle “Can be used offline” in the app’s settings, generate a new profile from the app’s existing data sources, and publish, without ever leaving the maker experience or requesting elevated access. Microsoft’s stated rationale is reasonable on its face: reduce dependency on admin resources, shorten the path from idea to working field app, and let the people closest to the operational problem build the solution. For a citizen developer with a genuine business need and no admin relationship to lean on, that is a meaningful unblock.

The Governance Question Nobody Configured

The trade being made here is not really about ease of use. It is about who decides that a given business process is allowed to run detached from the server for hours or days at a time, and who is accountable when that detachment causes a problem. Under the old model, an admin reviewing an offline profile request had at least the opportunity to ask whether a given table should sync offline at all, whether the data involved needed tighter access controls, or whether the use case justified the storage and sync overhead. Under the new model, that opportunity does not exist unless an organization builds a replacement for it.

This is not a hypothetical concern specific to one industry. Any Dynamics 365 or Power Platform environment with field technicians, warehouse staff, inspectors, or delivery personnel is a candidate for exactly the pattern described above: a well-intentioned maker solves a real connectivity problem, and the governance layer that used to exist by default is simply gone unless someone rebuilds it deliberately. Organizations that have invested in a Center of Excellence practice are better positioned here, but a CoE toolkit built around monitoring app creation and DLP policy does not automatically extend visibility into offline profile configuration specifically, since that setting lives inside the app rather than as a separate governed artifact.

Where the Ceiling Actually Sits

Setting governance aside, the built-in offline engine that now powers this has real technical boundaries that a maker moving quickly can hit without realizing it. Dataverse enforces a hard cap of three million total records synced per offline profile, counting hidden system tables the platform uses internally to support offline mode, and a profile that exceeds it fails to sync rather than degrading gracefully. Each table in a profile is limited to fifteen relationships, only one of which can be a many-to-many or one-to-many type, and an offline profile can include at most fourteen image columns across every table involved. Several capabilities common in online apps simply are not supported offline at all: non-Dataverse connectors such as SharePoint or Excel, virtual and elastic tables, calculated and rollup fields (since there is no client-side engine to reevaluate them), the Relate and Unrelate functions, and self-referential or multi-level relationship lookups.

The foreground-sync behavior that caused the technician’s missing notes in the opening scenario is arguably the most consequential limitation for business planning, because it is invisible until it causes a problem. Power Apps only synchronizes offline data while the app is actively running and the device screen is unlocked. There is no background sync service quietly reconciling data the way a native mobile app with push-based sync might. A field worker who closes the app, locks their phone, or switches to another task mid-shift has effectively paused synchronization, and nothing in the default experience tells them that has happened. For a use case involving safety documentation, chain-of-custody records, or time-sensitive service confirmations, that gap deserves explicit attention before the app reaches production, not after an audit finds it.

A Practical Path Forward

None of this argues for reversing the democratization Microsoft has enabled here; the administrative bottleneck it removed was real; a field team should not wait weeks for a platform team to configure something a maker can now do safely in an afternoon. The more useful response is to treat offline-enabled canvas apps as a specific category worth a lightweight review step, separate from the general app governance an organization already applies. That review does not need to be heavy. It can be as simple as requiring any app with offline mode enabled to pass through a short checklist before it reaches production users: confirming the data involved does not exceed reasonable volume for the sync limits described above, confirming the business process can tolerate the foreground-only sync behavior or has been explicitly designed around it (a startup screen reminder, a manual sync button, a status indicator showing pending changes), and confirming someone owns monitoring the Sync Error table for that app rather than assuming silence means success.

It also means updating whatever Center of Excellence monitoring already exists to specifically flag apps where offline mode has been enabled, since that is now a maker-level decision rather than an admin-level one, and the two are not tracked through the same audit trail by default. An organization that already has DLP policies and environment strategy in place is not starting from zero here, but it should not assume that existing governance automatically covers a setting that used to require an admin’s hands and no longer does.

The underlying capability is genuinely useful, and for the right use case, three weeks of unblocked development against three months of waiting for a platform team is not a close call. The organizations that get real value out of this change will be the ones that pair the speed with a deliberate answer to the question the admin center used to answer by accident: who checks this before it goes to the field. Routeget Technologies has walked several clients through exactly this kind of governance retrofit, and the pattern that works best treats offline enablement as a specific, named checkpoint rather than folding it into a general app review that was never built to catch it.

#PowerAppsOffline #CanvasApps #FieldMobility #CitizenDeveloperGovernance #DataverseSync #PowerPlatformGovernance

Your Dynamics 365 Power BI Dashboards Are Getting Faster, Not Instant

IT and finance leader reviewing a real-time analytics dashboard on a wall-mounted monitor in a modern office

An IT Director I know sat through a Monday operations review where the COO pointed at a Power BI inventory dashboard and asked why it still showed Friday’s numbers. The dashboard was labeled “real-time” in the workspace title, a name someone had chosen two years earlier and nobody had revisited since. It wasn’t a bug. It was the honest output of a reporting pipeline that moved data from Dynamics 365 Finance and Operations to Power BI through several intermediate stops, each one adding its own delay before a transaction became a chart.

That gap between when something happens in the ERP and when a decision-maker can see it is the actual cost center in most Dynamics 365 analytics programs, even when nobody puts a dollar figure on it. Microsoft closed a meaningful part of that gap this year with a change that makes Dynamics 365 Power BI dashboards measurably fresher, and the result is worth understanding before your team assumes “real-time” now means what the word implies.

Where the lag actually came from

Most organizations running Dynamics 365 Finance and Supply Chain Management have historically moved data into Power BI through some version of the same pattern: an export process pulls records out of the operational database, writes them as flat files, a separate conversion step turns those files into the columnar format analytics tools actually want, and only then does the data land somewhere Power BI can query it efficiently. Under the older Fabric Link architecture, that meant Dataverse writing data out as CSV first, then a second process converting that CSV into Delta Parquet before it reached the Fabric lakehouse. Each of those stages is a place where a batch job can queue, a conversion can lag behind incoming volume, or a large table can simply take a while to work through.

Layer scheduled Power BI refreshes on top of that, and the staleness compounds. A report built on imported data can only be as fresh as its last refresh cycle, and refresh frequency has practical ceilings tied to licensing tier and workload size. The net effect for a lot of finance and supply chain teams was dashboards that were accurate but rarely current, off by anywhere from thirty minutes to an hour depending on the day’s data volume and where in the refresh cycle a viewer happened to open the report.

What actually changed for Dynamics 365 Power BI dashboards

Microsoft announced general availability of low-latency sync for Fabric Link in a Power Platform blog post published June 9, 2026, and it targets exactly that CSV hop. The new sync engine writes data from the Dataverse database directly into Delta Parquet format in OneLake, removing the intermediate serialization step entirely. Fewer stages means fewer places for a job to fail, less contention on shared resources during the conversion, and a simpler retry path when something does go wrong.

Solution architect at a dual-monitor workstation reviewing an abstract data pipeline and sync architecture diagram

The throughput difference Microsoft cites for Finance and Operations apps specifically is substantial: table sync that previously ran in the range of 100,000 to 700,000 records per hour now reaches upwards of 1 million records per hour per table, under lab conditions the company is careful to note may not match every production environment exactly. Dynamics 365 customer engagement apps see a comparable improvement in delta sync latency, though Microsoft hasn’t published an equivalent throughput figure for that side of the platform. Paired with Power BI’s Direct Lake mode, which queries the Delta tables in OneLake directly instead of importing a copy into the report, the combination removes both sources of staleness at once: the pipeline delay and the refresh-schedule delay.

The rollout followed a staged regional schedule rather than a single cutover. Early release stations had it first, European, Canadian, and Indian environments picked it up in late June 2026, Asia Pacific, Japan, the UAE, Australia, and the UK followed in early July, and the remaining stations, including most of the Americas, were targeted for general availability by the end of July 2026. Microsoft flagged those windows as approximate and subject to change based on deployment health, which is a reasonable caveat for any organization trying to plan a go-live date around it.

What “near real-time” actually buys you

Here is the detail worth putting in front of whoever asked for real-time dashboards in the first place: this is a genuine and measurable improvement, but it is not streaming analytics. Practitioner reporting on the feature places typical data freshness in the range of fifteen to forty-five minutes after a transaction posts, down meaningfully from the roughly sixty-minute staleness common under the old architecture and refresh-schedule combination, but still a real interval. If your business actually needs second-by-second visibility into something like a production line sensor feed or a live transaction stream, that’s a different Fabric capability, Real-Time Intelligence, built around event streams and purpose-built for that use case rather than general ERP reporting.

Setting that expectation correctly matters more than the technical detail, because a COO who was told a dashboard is “real-time” and then watches it lag by half an hour during a busy close period will lose trust in the tool faster than one who was told upfront to expect fifteen-to-forty-five-minute freshness and sees exactly that. The fix here is genuinely good news for finance and supply chain reporting. It just isn’t the specific thing the word “real-time” tends to promise in a boardroom conversation.

The decisions this forces onto your roadmap

For organizations already on Fabric Link, adopting the new engine isn’t automatic. Existing links have to be unlinked and reconnected once a given environment’s region has been enabled, and Microsoft is explicit that relinking triggers a full initial resynchronization of every configured table, not an incremental catch-up. For a large Finance and Operations environment with years of transaction history, that’s not a trivial operation to schedule during business hours, and it’s worth treating as a planned cutover with its own change window rather than a background toggle. You can confirm a link has moved to the new engine by checking the Azure Synapse Link section in the admin experience for a “low-latency mode” flag against the profile.

There’s a version dependency to check before assuming your environment even qualifies. Microsoft’s guidance points organizations to verify their Finance and Operations build against the minimum supported version documented for low-latency sync, commonly cited around release 10.0.46 and later builds; if your environment hasn’t been kept current, that’s worth confirming with your applications team before the migration gets scheduled rather than after.

There’s also a budget conversation worth having early. Fabric Link’s replication model increases Dataverse storage consumption, since the platform is now maintaining a synchronized copy of operational data inside the Fabric environment; the compression Delta Parquet provides offsets some of that, but not all of it, and IT Directors sizing next year’s Fabric capacity should factor that in rather than discovering it in a usage report. Organizations that specifically need data exported into storage accounts they control, rather than accessed through Fabric shortcuts, still have Azure Synapse Link as an alternative path, though it carries its own Spark pool compute costs that scale with refresh frequency and change volume.

Finally, this is a reasonable moment to revisit whether your organization is still running the older Export to Data Lake integration. Microsoft’s messaging has been consistently pointing customers toward Fabric Link as the forward path, and while no hard retirement date has been published as of this writing, an environment still depending on the older CSV-based export is not going to benefit from any of the improvements described here. Rolling that conversation into the same project as the low-latency migration, rather than treating them as separate initiatives six months apart, saves a second round of testing and stakeholder communication.

Getting the rollout right

None of this requires a rebuild of your analytics estate. It requires a version check, a scheduled relink with real downtime planning around the resync, an honest conversation with the business about what “near real-time” will and won’t deliver, and a capacity plan that accounts for the storage shift. Organizations that have gone through a few rounds of Dynamics 365 and Power BI platform changes tend to treat this kind of update as routine infrastructure work rather than a special project, which is generally the right instinct. Routeget has walked several clients through exactly this kind of Fabric Link migration, and the pattern that separates a clean cutover from a messy one is almost always the same: confirm the prerequisite build first, schedule the resync deliberately, and set the freshness expectation with stakeholders before the new dashboard goes live, not after someone notices the timestamp.

#PowerBI #MicrosoftFabric #DynamicsFinanceOps #DataLatency #DirectLakeMode #FinanceReporting

Data Latency Direct Lake Mode Dynamics Finance Ops Finance Reporting Microsoft Fabric Power BI

Configuring Dynamics 365 Email Sensitivity Labels Without Losing Copilot

IT security and compliance professional reviewing an email data classification and encryption dashboard

A Customer Service administrator at a regulated financial services firm spent most of Q1 rolling out Microsoft Purview sensitivity labels across the organization’s email traffic, a project driven by a compliance mandate that had nothing to do with the contact center. Once Dynamics 365 email sensitivity labels went live in the Customer Service workspace, the security team considered the job done. Three weeks later, a supervisor noticed that case summaries were quietly missing for a cluster of escalated tickets, and Copilot’s intent detection wasn’t firing on a subset of inbound email at all. The two projects, security and AI, had never been evaluated together, and nobody had checked whether the feature that satisfied the compliance mandate was compatible with the feature the contact center had spent the prior year building its workflows around.

That collision is becoming common enough to plan for directly. Data sensitivity labels for email reached general availability in Dynamics 365 Customer Service on May 1, 2026, giving service representatives a native way to classify and protect outbound and inbound messages using labels defined centrally in Microsoft Purview. It is a genuinely useful capability, and for regulated industries it is close to mandatory. But it was shipped as a security feature, evaluated by security teams, and its interaction with Copilot-driven case automation is easy to miss until an agent asks why a summary never generated.

What Actually Ships With the Feature

The capability itself is narrow and well-scoped: agents get a Sensitivity Label dropdown in the command bar, available both when reading an inbox item and when composing or replying to an email, inside the Customer Service workspace and Contact Center apps. Labels are not created in Dynamics 365 at all. They are authored in the Microsoft Purview compliance portal, under Information Protection, where an administrator defines the label’s name, priority, scope, and, critically, its protection settings, including whether it carries encryption, a Do Not Forward restriction, or a visual marking like a watermark or header. Once that label policy is published tenant-wide, it becomes available inside Dynamics 365 without any additional publishing step on the Dataverse side.

What surprises a lot of technical teams is how much of the actual behavior is inherited from Purview rather than configured in Dynamics 365. A label that carries an encryption policy behaves identically whether it was applied from Outlook, from Word, or from a Customer Service email form: the message becomes a protected, rights-managed object the moment the label is applied, not a cosmetic tag on a Dataverse record.

Configuring Dynamics 365 Email Sensitivity Labels: The Two-Step Setup

The rollout has two distinct halves, and skipping the prerequisites is the most common reason a pilot stalls. Before anything happens inside Dynamics 365, the environment needs an email server profile configured for Server-to-Server Authentication against the same tenant’s Exchange Online, and server-side synchronization for email has to already be running. Neither of those is new infrastructure specific to this feature, but plenty of sandbox and dev environments never had them fully wired up, since basic email testing doesn’t require them.

With that in place, enabling the feature itself is a single toggle: in the Power Platform admin center, under the target environment’s Settings, expand Email, open Email Settings, and switch on “Enable data sensitivity labels for emails.” The second half of the work happens in Power Apps rather than the admin center. Inside the relevant solution, add the Email table’s main form to the solution if it isn’t already there, open the form in the designer, locate the “Sensitivity label” column, and drag it onto the canvas. On its own that column just stores a value, so the practical step is adding the “Email sensitivity label control” component to the same field and configuring it, then saving and publishing the form. Skip that control and the column exists on the record but agents never see anything to interact with.

One detail worth flagging to the security team directly: the Entra ID identity associated with the mailbox needs its own permissions in Microsoft Purview to apply the labels that are relevant to that queue. This is a common gap in shared-mailbox and queue-based routing setups, where the mailbox identity was provisioned years ago for basic send/receive and never touched again.

Solution architect configuring email sensitivity label settings in a Dynamics 365 environment

How Enforcement Actually Behaves in Practice

Once labels are live, the enforcement rules mirror what a user would expect from Outlook, and that consistency is deliberate. A label like Do Not Forward or Do Not Reply restricts the corresponding action for recipients inside the organization, and an agent cannot manually downgrade a message to a less restrictive label than the one already applied, so a “Confidential” thread can’t be quietly relabeled “General” to make it easier to forward externally. Replies and forwards inherit the label of the message being responded to by default, which is the behavior most compliance teams actually want, since it removes the judgment call from the agent in the moment they’re least likely to think about it. Attachments carry their own labels independently, and when an attachment’s label conflicts with the email’s label, the interface surfaces which one takes precedence rather than silently picking one.

Where this gets operationally interesting is auto-labeling. Purview supports content-based auto-labeling, where a label gets applied automatically based on what the message contains, and that setting lives entirely in Purview, invisible from the Dynamics 365 side. A queue that starts seeing a spike in encrypted, auto-labeled mail didn’t necessarily have a policy change made against it directly. Somewhere upstream, a Purview label’s auto-apply conditions matched more content than before.

The Gap Nobody Tests For: Encrypted Mail and Copilot

This is the part of the rollout that deserves its own test plan rather than a footnote. When a label applies encryption protection, Dataverse does not decrypt or store the message content. The email still appears in the case timeline, so an agent knows the correspondence exists, but the body is not readable inside the application at all. Agents are redirected to Outlook on the web to open and decrypt the message there.

That gap propagates directly into every Copilot capability that depends on reading email content. Case summarization skips encrypted messages entirely, meaning a case summary generated near the end of a long thread may be missing the specific email that actually contains the customer’s core complaint, if that thread’s most detailed message happened to carry a Confidential-and-Encrypted label. Case enrichment, intent detection, and any Copilot workflow built around analyzing inbound email content behave the same way: they simply do not see encrypted mail, and there is no fallback summarization or partial analysis. From the AI feature’s perspective, the message is invisible, not redacted.

For a technical team that built intent-based routing or auto-summarization as part of a Copilot rollout, this means the encryption policy decided in a completely separate Purview governance project can silently degrade the reliability of automation the contact center is depending on operationally. Neither team is wrong about their own configuration. The interaction between the two simply isn’t visible from inside either admin surface on its own.

Rolling This Out Without Breaking What Already Works

The practical fix isn’t to avoid sensitivity labels, since for a regulated organization that usually isn’t optional, and blanket-disabling encryption defeats the purpose of the compliance project in the first place. The fix is sequencing the two conversations that normally never happen in the same room. Before a label policy that carries encryption goes anywhere near production mailboxes tied to Customer Service queues, pull a sample of real case threads that currently drive summarization or intent detection, and run them through the label to see which specific messages would become invisible to Copilot under that policy. That test takes an afternoon and reliably surfaces problems that would otherwise take weeks to notice in production, one confused agent at a time.

It’s also worth treating auto-labeling as a change management event even though it technically lives entirely in Purview. Any time compliance adjusts an auto-apply condition on a label with encryption attached, that change has a direct, measurable effect on Copilot coverage in the contact center, and the service delivery team should be in the notification loop for that change, not discovering it through a drop in summarization quality. Finally, agents need to know the Outlook-on-the-web redirect path exists and why it exists, rather than treating an unreadable encrypted email in the case timeline as a bug to escalate. A short addition to onboarding material covers this permanently; a support ticket every time it happens doesn’t.

Routeget has walked several clients through exactly this sequencing problem when a compliance-driven Purview rollout landed on top of an existing Copilot investment in Customer Service, and the fix is almost always coordination rather than reconfiguration. Getting the security and the AI roadmap talking to each other before go-live is considerably cheaper than untangling the symptoms afterward.

#DynamicsCustomerService #DataSensitivityLabels #MicrosoftPurview #CopilotService #EmailSecurity #ComplianceGovernance

Compliance Governance Copilot Service Data Sensitivity Labels Dynamics Customer Service Email Security Microsoft Purview

Business Central 1099 Thresholds Didn’t All Move Together in 2026

Finance controller reviewing a tax compliance and vendor payments dashboard on a wall-mounted monitor in a modern office

A controller closing out Q3 payables in Dynamics 365 Business Central recently found herself staring at a vendor card for a landlord who’d been paid $1,400 in rent through September. Under the threshold she believed applied for 2026, that vendor wouldn’t need a 1099-MISC at all. She was wrong about that specific case (rent does cross the new reporting line), but the mistake that actually worried her had happened two months earlier, when she updated every box minimum in the company’s Vendor Box Setup to a single new number because that was the figure everyone in her network was repeating. Attorney gross proceeds and royalty payments to a handful of consultants quietly stopped generating 1099s the moment she made that change, because neither of those categories moved.

That’s the problem with updating Business Central 1099 thresholds for 2026: the increase is real and significant, but it applies to almost none of Form 1099-MISC uniformly. For a finance team running Business Central, the risk isn’t that they’ll miss the change entirely. Microsoft’s own release notes and every ERP consulting blog covered it. The risk is that they’ll apply it correctly to the one box everyone talks about and incorrectly to the six or seven boxes nobody mentions, inside a system that makes it just as easy to set a wrong minimum as a right one.

What actually changed for tax year 2026

For payments made on or after January 1, 2026, the reporting threshold for Form 1099-NEC nonemployee compensation, and for several categories on Form 1099-MISC, rises from $600 to $2,000. That covers rents, prizes and awards, other income, medical and health care payments, crop insurance proceeds, section 409A deferrals, and nonqualified deferred compensation. It does not cover royalties or broker payments in lieu of dividends and interest, which stay at a $10 minimum, and it does not cover gross proceeds paid to attorneys or purchases of fish for resale, which stay at $600. Interest, dividend, and retirement distribution reporting on Forms 1099-INT, 1099-DIV, and 1099-R sit outside this change entirely, still governed by their own long-standing $10 minimums. Starting in 2027, the $2,000 figure is subject to inflation adjustment, which means the number itself won’t stay fixed even for the categories it does apply to.

One rule that didn’t move at all: any business filing ten or more aggregate information returns across all form types in a calendar year is still required to file electronically rather than on paper. That threshold, which has applied since the aggregation rule took effect for returns filed in 2024, catches most Business Central customers well before they’d ever consider paper filing as an option, which makes the electronic filing path the default rather than a special case.

Business Central 1099 thresholds live box by box, and nothing warns you they differ

Business Central’s current 1099 architecture, rebuilt in the 27.2 release toward the end of 2025, replaced the older preprinted-forms workflow with a set of purpose-built pages: IRS Forms Setup for email templates, IRIS credentials, and TIN protection controls; IRS Reporting Periods for managing each year’s cycle, with a copy-forward action to bring last year’s configuration into the new period; Vendor Box Setup for mapping each vendor to the specific 1099 form and box their payments belong in; and a Form Documents page for generating, reviewing, and transmitting the actual forms.

Accounts payable specialist at a dual-monitor workstation reviewing a vendor tax form configuration screen with a numeric threshold table

The box minimum lives at the box level by design, which is exactly right in principle. The trouble shows up in practice, because nothing in that setup screen warns a controller that the value they’re about to paste into every row isn’t the same value for every row. A company that runs an “Update Form Boxes” pass once a year, changes the number that made the news, and moves on will end up with 1099s that look complete and are quietly wrong. Under-reporting a required form doesn’t just create IRS exposure; it creates a vendor relations problem when that vendor’s own accountant asks where their form went, and a documentation problem when an auditor asks why the threshold on file doesn’t match what’s printed in the IRS’s own instructions for that box.

What native filing now covers, and where it still stops

The bigger structural change in Business Central’s 1099 handling isn’t the threshold at all. It’s that the platform can now submit forms directly to the IRS’s Information Returns Intake System, IRIS, through an API integration that reached general availability on November 1, 2025, for Business Central Online. Forms transmit without a manual export and re-import step, and an IRIS Transmission page tracks status so finance doesn’t have to guess whether a batch went through. Copy B, the version vendors receive, prints or emails as a plain-paper substitute rather than requiring the preprinted stock that year-end close teams used to scramble to order.

That’s a meaningful reduction in the case for a third-party 1099 add-on, but it isn’t a full replacement for one, and it’s worth being specific about why. As of the current release, Business Central’s Form Documents page has no option to print or email every vendor’s form in a single action; each one has to be handled individually, though Microsoft has flagged bulk printing and emailing as coming in a near-term update. TIN matching against IRS records isn’t part of the native workflow, so a company that wants pre-filing verification that a vendor’s name and taxpayer ID actually match still needs to run that check somewhere else. State filing is out of scope too: IRIS handles federal transmission, and any state that doesn’t participate in the Combined Federal/State Filing Program still needs its own submission, which is exactly the kind of gap that standalone 1099 compliance apps in the Business Central ecosystem were built to close and continue to be relevant for. Correction and amendment handling after an original form has already transmitted is also thinner in the native tool than in most dedicated filing services, which matters more than it sounds like it should, since threshold-driven errors are precisely the kind of mistake that generates corrections.

What this means for the close calendar, not just the tax calendar

None of this is a reason to delay adopting the native IRIS integration. Eliminating the preprinted-forms supply chain and the manual transmission step is a genuine operational win, and most finance teams should move onto it as their filing method regardless of what else they use alongside it. The point is narrower: the threshold change is a forcing function to actually open Vendor Box Setup and check every box against the IRS’s own 2026 instructions, line by line, rather than trusting whatever number was last typed in.

Finance and compliance team reviewing a year-end tax compliance checklist and reconciliation chart in a meeting room

That review belongs on the calendar before the fourth quarter closes, not in the scramble between January 1 and the filing deadline. It’s worth having someone outside of accounts payable, ideally whoever owns tax compliance or the external CPA relationship, sign off on the box configuration once it’s set, since the people most likely to hear about the threshold change first are the ones least likely to know which of the seven or eight affected categories it actually touches. If the organization already licenses a third-party 1099 or AP compliance app for TIN verification, bulk processing, or state filing, this is also the moment to confirm that app’s own 2026 configuration has been updated to match, rather than assuming it inherited the change automatically from Business Central.

Routeget has walked several clients through exactly this kind of box-by-box reconciliation ahead of a release change, and the pattern holds regardless of company size: the failure mode is never a controller who ignores a well-publicized rule change. It’s a controller who applies it correctly to the one number that made headlines and never checks the six that didn’t.

#BusinessCentral #1099Thresholds #VendorBoxSetup #IRISFiling #YearEndClose #TaxCompliance

1099 Thresholds Business Central IRIS Filing Tax Compliance Vendor Box Setup Year End Close

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

Cost Estimate Method Enterprise ERP Financial Close Project Accounting Project Operations Revenue Recognition

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

Cloud Governance Compliance Risk Customer Managed Key Data Sovereignty Dataverse Encryption Key Management

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

Content Security Policy Enterprise App Dev Power Apps Code Apps Power Apps Licensing Power Platform ALM Power Platform Governance

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.

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

Cloud Cost Management Data Analytics Strategy Fabric Capacity Migration IT Budget Planning Microsoft Fabric Power BI

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

Contact Center Conversation Orchestration Direct Inward Dial Dynamics Customer Service Omnichannel CX Unified Routing

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.

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

Business Central Digital Transformation Discrete Manufacturing ERP Capacity Planning Manufacturing Scheduling Production Planning