Bridged Payment Clearing Just Became Mandatory in Dynamics 365 Finance

Finance professional reviewing a bank reconciliation dashboard showing bridged transaction clearing

A technical consultant reviewing the release notes for Dynamics 365 Finance and Operations version 10.0.49 will hit a line that looks routine until it isn’t: automatic clearing of bridged transactions during bank reconciliation, previously something you could turn on when you were ready, is now mandatory. Self-update customers got the build on September 11, and autoupdate production environments follow on October 2. Anywhere bridging accounts, methods of payment, or bank reconciliation parameters were never fully configured, that gap stops being a backlog item and becomes an active problem in the general ledger the moment the update lands.

This is the kind of change that rewards people who read upgrade notes closely and punishes people who don’t. Bridged payment clearing isn’t a new concept in F&O, Microsoft first shipped the automatic version of it a couple of release waves back, but plenty of environments left it disabled because the manual clearing process, while tedious, was at least predictable. Mandatory rollout removes that opt-out, so it’s worth walking through what bridging actually does, what specifically changes in 10.0.49, and what a technical team should check before the autoupdate window closes in early October.

Finance professional reviewing a bank reconciliation dashboard showing bridged transaction clearing

How Bridged Payment Clearing Actually Works

A bridging payment is a payment that posts to the general ledger in two steps instead of one. When a vendor or customer payment is created, the amount lands first in an intermediate bridging account rather than directly in the bank main account. It only moves to the real bank account once the transaction actually clears, which is confirmed during bank reconciliation. The gap between those two events, sometimes hours, sometimes several business days for checks or ACH batches, is exactly the timing problem bridging accounts exist to solve. Without one, your cash position either overstates funds that haven’t cleared yet or requires someone to manually track which payments are still in flight.

Centralized vendor payments add a second layer of complexity on top of that timing gap. When a shared services organization pays vendors out of one legal entity on behalf of several operating entities, the bridging transaction has to reconcile correctly across that entity boundary, not just across time. That’s the specific scenario the 10.0.49 changes target, and it’s also the scenario most likely to have been left half-configured, because centralized payment setups tend to get built by one team and handed off before every downstream parameter gets revisited.

Abstract illustration of payments flowing through a bridging account to a final bank account

What Changes in Version 10.0.49

Three related capabilities move from optional to mandatory in this release: automatic clearing of bridged transactions through advanced bank reconciliation, the extension of that clearing to centralized bridged vendor payments specifically, and use of the latest exchange rate when posting bank transactions. A fourth item, clearing bridged customer payments automatically on the accounts receivable side, reaches general availability this same month, giving Finance teams parity between the vendor and customer sides of bridging for the first time. Microsoft also shipped a preview capability to review automatic bank reconciliation matching results before they post, along with performance improvements to bridge transaction selection that matter once you’re running this at real transaction volume rather than in a sandbox.

The practical effect is that any environment relying on the older manual clearing workflow, where a user posts a general journal by hand after reconciliation, no longer has that as a supported path once the mandatory feature activates. If your bank reconciliation parameters, methods of payment, or bank account records were never updated to support automatic clearing, the reconciliation worksheet’s “mark as reconciled” action will attempt to post clearing journals against configuration that isn’t there, and that’s where things go sideways.

Configuring It Before the Update Lands

The setup itself isn’t complicated, but it touches three separate configuration surfaces, and missing any one of them is enough to cause posting failures. Start in Feature Management and confirm that “Automatic clearing of centralized bridged vendor payments during bank reconciliation” is actually enabled rather than assuming it inherited a default; feature flags introduced in earlier waves don’t always carry forward cleanly into new environments cloned from production.

Next, check the methods of payment used for the affected vendor and customer payment types. The “Bridging account by bank account” parameter determines which account the system treats as the offset for the bridging entry: turned on, it pulls the bridging account configured on the bank account itself, and turned off, it falls back to whatever bridging account is set on the method of payment record. Mixed configurations, where some payment methods rely on the bank account setting and others rely on their own override, are a common source of confusion during testing, so it’s worth documenting which methods use which approach rather than assuming consistency.

Bank account records need attention in two places. On the General tab, confirm the bridging account itself is populated and points to a valid, active main account. On the Reconciliation tab, the “Clear bridged transactions during reconciliation” toggle needs to be on; if it’s off, the system still requires someone to clear bridging payments through a manual general journal, which defeats the purpose of the mandatory automation and will look like the feature “isn’t working” when really it’s configured to not run. Finally, in Cash and Bank Management parameters, the clearing journal name on the Bank reconciliation tab has to point to a journal name that’s actually set up to accept these postings; a blank or misconfigured journal name is a quiet failure point that won’t surface until someone tries to reconcile a real bank statement.

Handling What Doesn’t Clear Automatically

Even with configuration correct, individual transactions will occasionally fail to clear automatically, usually because of a data issue on the underlying payment rather than a setup problem. Dynamics 365 Finance includes a periodic batch job for exactly this situation: Cash and Bank Management > Periodic Tasks > Clear Bridged Transactions lets you select a specific reconciliation ID and resubmit the clearing attempt as a batch process rather than trying to force it through the interactive reconciliation worksheet again. Building a habit of checking this job’s history after each reconciliation cycle, at least for the first few months after the mandatory rollout, will catch configuration gaps faster than waiting for a period-end variance to surface them.

The posting date logic is also worth knowing before someone asks why a clearing entry landed where it did: the system uses the earlier of the reconciliation cut-off date or the system date, not always the date the bank statement itself is dated. For teams doing month-end close under a tight calendar, that detail affects which period a clearing entry hits and is easy to get wrong if you’re reasoning from the statement date alone.

Testing Before the Autoupdate Window Closes

Self-update customers already have this behavior live as of September 11. Autoupdate customers have until October 2 before it arrives automatically, which is a narrow but workable window to validate configuration in a sandbox tier rather than discovering gaps in production. The most useful test isn’t a single sample transaction, it’s running a full reconciliation cycle against a realistic batch of centralized vendor payments, ideally spanning more than one legal entity, and confirming the clearing journals post to the correct centralized entity with the correct offset accounts. Teams that skip straight to production validation tend to find out about a missing bridging account setup during the first live bank statement import after go-live, which is a worse time to find out.

Extending the same test to accounts receivable is worth the extra hour, since the customer-side clearing feature is landing in the same window and shares enough of the underlying mechanics that a gap on one side often points to the same gap on the other.

Routeget Technologies has walked several clients through advanced bank reconciliation configuration changes like this one, and the pattern holds across most of them: the technical setup itself takes an afternoon, but tracking down which of dozens of payment methods and bank accounts were configured inconsistently over several years takes longer than the actual fix. Treating this mandatory change as a prompt to audit that configuration now, rather than after a reconciliation cycle breaks, is the difference between a routine update and an unplanned fire drill.

#BridgedPaymentClearing #BankReconciliation #AccountsPayable #DynamicsFinanceOps #CashManagement #ERPGovernance

Dataverse Capacity Got Bigger This Year. Your Storage Governance Still Needs to Catch Up

IT director reviewing a Dataverse storage capacity dashboard showing database, file, and log usage

An IT director we spoke with recently pulled up the Power Platform admin center in January expecting the same tired warning banner about Dataverse capacity that had been sitting there since October. It was gone. Database storage for their Dynamics 365 Finance and Supply Chain Management environment had jumped from 90 GB to 125 GB overnight, with no purchase order, no change request, and no email from their partner. The natural conclusion was that the capacity problem had quietly solved itself. Four months later, the same environment tripped a new kind of alert: a file storage overage notice, even though database usage looked flat. Nothing had been deleted or migrated. The ground underneath the numbers had simply moved.

That is roughly where most Dynamics 365 and Power Platform customers stand right now with Dataverse storage. Microsoft raised default capacity entitlements significantly in December 2025, restructured how that capacity is reported and managed, and then made a second, narrower adjustment in the spring that reclassifies certain metadata between storage types. Individually, each change is well documented. Together, they change what a capacity plan built a year ago actually means, and CIOs and IT directors who treat the December Dataverse capacity increase as a problem solved rather than a system redesigned are going to be surprised by their own admin center in a quarter or two.

What changed in Dataverse capacity this December

The default database capacity increase was substantial and varied by product. Copilot Studio, Power Apps per-app plans, and Power Automate process licenses moved from a 5 GB to a 15 GB baseline. Dynamics 365 CRM applications, including Sales, Customer Service, Field Service, and the Contact Center, moved from 10 GB to 30 GB. Dynamics 365 Customer Insights went from 25 GB to 45 GB. On the ERP side, Standard tier products including Finance, Supply Chain Management, Project Operations, Commerce, and Human Resources rose from 60 GB to 90 GB, while the Premium tier for Finance and Supply Chain Management increased from 90 GB to 125 GB. File storage roughly doubled across most of these same products, though Microsoft did not publish the same level of per-product detail it did for database capacity. Log storage was left untouched.

The more structurally important change sits underneath those numbers. Finance and Operations customers previously managed two separate storage pools: one for the Operations database and one for Dataverse. As of December, those pools merged into a single combined entitlement. For an organization that had been carefully tracking two distinct capacity ceilings, this is not a cosmetic simplification. It changes how consumption trends read, and it means a team that spent the last two years building spreadsheets or Power BI reports to track Operations and Dataverse separately needs to rebuild that tracking around a single number.

Three capacity types, not one

Alongside the entitlement increase, Microsoft has been rolling out a new capacity reporting model that separates Dataverse storage into three distinct types: database, file, and log. This is not universal yet. Organizations still on the legacy model see a single blended capacity figure, while those on the new model get per-type visibility along with a mechanism called cross-capacity-type borrowing. Under that mechanism, unused database capacity can offset a log or file overage, and unused log capacity can offset a file overage, but file capacity cannot offset shortfalls anywhere else. A tenant only registers as officially over capacity after all of that eligible borrowing has already been applied.

Abstract illustration of database, file, and log storage blocks connected by data flow lines representing Dataverse capacity

This matters for budget owners specifically because it changes what an overage notification actually tells you. A file storage warning on an environment that appears to have plenty of headroom in its combined number is not necessarily a sign that the tenant needs more storage overall. It may simply mean the tenant has database or log capacity sitting unused that isn’t automatically flowing to cover the file shortfall, either because the environment hasn’t moved to the new model yet or because the borrowing rules genuinely don’t apply in that direction. Before anyone approves a purchase of additional capacity, it is worth confirming which reporting model the tenant is actually on and whether the specific storage type in the alert is one that borrowing rules can even help with.

The April reclassification nobody budgeted for

In April 2026, Microsoft moved solution-aware tables and related metadata out of database storage and into file storage. Total consumption for an organization does not change as a result of this move, but the split between the two numbers does, and it does so without any corresponding change in what the organization is actually storing. A team that set a database utilization threshold as an internal early-warning trigger, say 70 percent of entitlement, may find that number drop for reasons that have nothing to do with actual data growth, while file utilization climbs for the same non-reason. Anyone reviewing a capacity trend line that spans this period without accounting for the reclassification is going to draw the wrong conclusion about whether their data growth rate is accelerating or slowing down.

Sales Premium customers got a further, separate adjustment in the same window: per-user file storage entitlement doubled from 250 MB to 500 MB, and the underlying tenant base storage figures for those environments moved as well. Microsoft’s own framing for these changes has been candid about the driver: AI-assisted features, Copilot experiences inside Dynamics 365 applications, and the broader push toward agentic workflows all generate metadata, context, and interaction history that traditional transactional storage planning never had to account for. Storage capacity planning built around transaction volume alone is now measuring the wrong thing.

What a capacity plan actually needs to do differently

None of this means the December increase was a bad deal for customers. Bigger entitlements at no additional cost are, on their own terms, a straightforward win, and organizations that were previously purchasing supplemental capacity to cover a gap that the new baseline now closes should go back and cancel or right-size that spending. The mistake is treating a larger number as the end of the exercise rather than the start of a different one.

The more durable response is to rebuild storage governance around the actual mechanics Microsoft has put in place rather than around the old assumption of one number that only ever goes up when you buy more. That starts with confirming, environment by environment, whether the tenant is on the legacy single-figure model or the new three-type model, since the two require genuinely different monitoring approaches. It continues with capturing a clean baseline now, broken out by database, file, and log where that visibility exists, so that the April reclassification and any future ones can be isolated from genuine consumption growth rather than blended into it. It also means understanding the capacity extension option Microsoft makes available once an environment crosses 80 percent utilization: a 45-day window to reduce usage or purchase additional capacity, capped at three extensions in a rolling 365-day period, which is a real safety valve but not one designed to be leaned on indefinitely. And it means deciding, deliberately and in advance rather than reactively during an incident, whether pay-as-you-go billing tied to an Azure subscription is the right overage mechanism for a given environment or whether reallocating from tenant pool capacity is preferable.

For finance and IT leaders who fund these environments, the practical takeaway is that Dataverse storage has moved from a mostly static line item to something closer to a cloud consumption model, with the reporting granularity and billing flexibility that implies, but also the volatility. That is a governance conversation as much as a technical one, and it is worth having before the next reclassification lands rather than after a budget line quietly moves for reasons nobody remembers agreeing to. At Routeget, the engagements that go smoothest are the ones where a client’s storage monitoring gets rebuilt around the new model proactively, rather than the ones where the first real conversation about it happens after an unexpected overage notice.

#Dataverse #DataverseStorage #PowerPlatformLicensing #ITGovernance #DynamicsFinanceOps #CloudCostManagement

What the Power BI PBIR Format Means for Dynamics 365 Reporting Teams

A solution architect reviewing a code diff and a business analytics dashboard on dual monitors in a modern office

A finance reporting team running Power BI over Dynamics 365 Finance and Operations data has a familiar problem: exactly one person can safely have the working capital dashboard open at a time. Everyone else waits, or worse, someone opens the file anyway, makes a change, saves over a colleague’s unsaved edits, and nobody finds out until a client asks why a visual disappeared. That is not a hypothetical. It is how nearly every Power BI report built on top of Dynamics 365 or Dataverse data has been managed since the tool existed, because a .pbix file is a single binary blob. There is no diff, no merge, no pull request, just a file lock enforced by social convention. The Power BI PBIR format changes that mechanic directly, and as of May 2026 it became the default way Power BI Desktop saves new reports, which makes this less a curiosity for early adopters and more a decision every Dynamics 365 reporting practice needs to make on purpose.

PBIR stands for Power BI enhanced report format, and it replaces the older single-file report.json approach (itself an earlier attempt at the same problem, now referred to as PBIR-Legacy) with a folder of small, human-readable JSON files. Microsoft first shipped it as a Desktop developer mode preview several years ago, but the May 2026 update made it the default for both new PBIX files and PBIP projects, meaning teams that never opted into the preview are now creating PBIR reports without necessarily realizing the storage model underneath them has changed.

What the Power BI PBIR Format Actually Changes on Disk

Open a PBIR report’s project folder and you will find a definition directory containing a pages subfolder, a bookmarks subfolder, a report.json for report-level settings, and a version.json that records which format version the report requires. Inside pages, each report page gets its own folder with a page.json and a visuals subfolder, and inside that, every single visual on the page gets its own visual.json file describing its position, formatting, and query. A bookmark becomes its own file too. This sounds like a lot of small files for what used to be one, and it is, but that granularity is the entire point: a change to one chart’s conditional formatting now shows up as a one-file diff instead of an unreadable delta buried inside a compressed binary.

Each of these JSON files declares a public schema URL at the top, and Microsoft has published those schemas on GitHub, which means a report can be opened, validated, and even edited in VS Code with real IntelliSense rather than guesswork. Objects get 20-character generated identifiers by default (something like 90c2e07d8e84e7d5c026), which is ugly to read in a diff but can be renamed to something meaningful through Power BI Desktop, with the caveat that renaming requires restarting Desktop for the change to stick. There is also a lesser-known annotations feature: name-value pairs that Power BI itself ignores completely but that a deployment script can read, which turns out to be useful for marking which page should be the default landing page in a given environment or flagging a visual for environment-specific suppression.

Abstract illustration of branching and merging version control lines connecting to report dashboard blocks

The Git Workflow This Finally Enables

None of the file structure matters much without source control actually using it, and this is where the practical shift happens. A pull request against a PBIR report can now show a reviewer exactly which visual changed and how, the same way a code review shows a diff of a function. Two developers working on different pages of the same report can genuinely work in parallel and merge without one silently overwriting the other, something that was structurally impossible with a monolithic .pbix. Fabric’s own Git integration, which connects a workspace to Azure DevOps or GitHub, extends this further by tracking reports and semantic models at the workspace level and preserving folder structure in the repository, though it is worth being precise here: the file format reaching general availability in Desktop and Fabric’s Git integration support for report and semantic model items reaching full production maturity are two different milestones, and as of this writing the latter is still documented as preview for several connection scenarios, including reports tied to Analysis Services live connections.

A report’s connection to its semantic model is itself stored declaratively, through either a byPath reference that opens the model in full edit mode alongside the report, or a byConnection reference that opens the report in live connect mode with only report-level measures editable. Which one a team chooses affects how much of the semantic model layer gets included in the same Git history as the report, and it is worth deciding deliberately rather than by whatever Power BI Desktop defaulted to on first save.

Why This Matters More for Dynamics 365 Reporting Portfolios

Generic Power BI advice tends to treat this as a nice-to-have for BI teams in general. For a Dynamics 365 F&O or Business Central reporting practice specifically, it addresses a sharper pain point. These environments accumulate large report portfolios fast: financial statement packages, inventory and demand dashboards, project cost tracking, often built by a rotating cast of internal analysts and external consultants over several years. Ownership gets murky, undocumented changes creep in before a board meeting, and when something breaks nobody can say with confidence what changed or when. Power BI Desktop’s version history feature, which also reached general availability in the May 2026 wave alongside the default PBIR change, gives that audit trail natively inside the desktop tool for the first time, which is directly relevant to any organization treating financial report changes as something that needs a change management trail rather than an honor system.

Deployment pipelines benefit in a related way. A report promoted from a development workspace to test and then production can carry annotation-driven configuration differences (a different default page, a different data source binding) without manual reconfiguration at each stage, and the promotion itself becomes something a pipeline log records rather than something a person remembers doing.

Rolling Out PBIR Without Breaking Anything

The rollout mechanics are straightforward but deserve a plan rather than an ad hoc toggle. PBIR is enabled through Power BI Desktop’s preview features under Options, and existing PBIR-Legacy reports convert automatically on the next save, with Desktop creating a backup copy first. That backup detail matters because there is no supported rollback path once a report has converted; the backup is the rollback path, and it lives in a local temp folder with a 30-day retention window, not somewhere a team should rely on long term. The sensible sequence is to pick one lower-stakes report first, ideally something without heavy custom visual dependencies, convert it, get comfortable with the folder structure and the Git workflow in a sandbox repository, and only then extend the practice to the financial statement packages where a mistake actually costs something. Establishing a branching convention (a feature branch per report change, a pull request before merging to the branch a production workspace tracks) before the first real conversion saves a team from learning that lesson under time pressure.

What Still Doesn’t Work Smoothly

A few limitations are worth knowing before committing a whole reporting portfolio to this model. Edits made directly in a code editor do not sync live; the report has to be reopened in Power BI Desktop for those changes to take effect, so treat external JSON edits as a batch operation rather than a live-editing workflow. Two developers can still step on each other if they edit the same page at the same time rather than different pages, since the conflict resolution is granular but not infinite. Service-side limits apply too: a report tops out at 1,000 pages and 1,000 visuals per page, and resource packages are capped at 300 MB, ceilings that rarely matter for a typical operational dashboard but are worth knowing about before designing something unusually large. And a handful of connection types, including push datasets, live connections to on-premises Analysis Services, and older model versions, are excluded from Git integration support entirely for now.

None of that undermines the core shift. Power BI reports built on Dynamics 365 data have functioned for years as single-owner artifacts, reviewed by nobody, versioned nowhere, and handed off through tribal knowledge. PBIR does not fix that automatically, but it removes the technical excuse for not fixing it. The teams that treat this as an application lifecycle management decision, with branching conventions, review checklists, and a deliberate rollout order, will get real governance out of it. The teams that flip the preview toggle and keep working exactly as before will just have smaller binary files. At Routeget, we have been sequencing client Dynamics 365 F&O reporting portfolios through this conversion starting with the highest-change-frequency reports rather than the highest-visibility ones, on the theory that the reports changing every month are where a missing audit trail actually costs someone time.

#PowerBI #PBIR #GitVersionControl #DynamicsFinanceOps #ReportGovernance #MicrosoftFabric

Configuring Time Entry Duration Controls in Dynamics 365 Project Operations

Project manager reviewing a timesheet approval dashboard showing a calendar grid of time entries

A project accounting lead doing month-end billing reconciliation pulls up a consultant’s timesheet and finds a single day logged at 26 hours. It is almost certainly a typo, someone meant to type 2.6 or fat-fingered an extra digit, but it has already been submitted, approved by a project manager who didn’t look closely, and is sitting in the queue for client invoicing. A few rows down, another resource has logged entries in odd fragments: 7 minutes here, 23 minutes there, none of which line up with the 15-minute billing increments the engagement’s rate card assumes. Neither error is malicious. Both are expensive to catch after the fact, and until this summer, Dynamics 365 Project Operations gave administrators no native way to stop either one at the point of entry.

That gap has started to close. Project Operations now ships two native time entry duration controls that reached general availability within about five weeks of each other in 2026: the ability to configure a maximum daily time entry duration (GA July 24, 2026, tracked in Microsoft 365 message center as MC1425968) and the ability to configure a minimum interval for time entry duration (GA August 31, 2026, MC1443022). Together they give Project Operations something it had previously left entirely to custom validation, whether that meant a Power Automate flow triggered on time entry creation, a plugin registered against the create and update messages, or, more commonly, nothing at all beyond a project manager’s attention during approval.

What the two controls actually do

The maximum daily duration setting lets an administrator define the ceiling on how many minutes a single resource can log across time entries for one calendar day. Per Microsoft’s own release messaging, the configuration is applied from the Parameters page, and it is evaluated every time a time entry is created or modified, not just at submission or approval. That timing detail matters more than it might first appear. It means a resource typing an obviously wrong duration gets an error immediately, in the same session, rather than discovering it later when a project manager rejects the entry or, worse, when it has already cleared approval and shown up on an invoice.

The minimum interval control addresses a different failure mode: durations that are technically valid but operationally useless. Once configured, Project Operations only allows time entries whose duration is a multiple of the value an administrator sets, for example 15 minutes or a full hour. A resource cannot log 22 minutes against a task if the organization has standardized on quarter-hour billing increments; the entry is rejected until it rounds to 15, 30, 45, or 60. Microsoft’s own framing for this feature is squarely about time-tracking policy compliance rather than data hygiene for its own sake, and the distinction is worth sitting with: this is not a cosmetic rounding feature, it is a control meant to make sure recorded time actually maps to how the organization bills or costs labor.

Abstract illustration of a clock face overlaid with a grid representing time entry duration increments

Neither setting appears to expose a granular default in Microsoft’s public documentation beyond the mechanism itself, but field configuration guidance published around the July rollout describes the daily maximum defaulting to a full 24-hour day, meaning 1,440 minutes, until an administrator tightens it. If that reporting holds in your tenant, the practical implication is that this feature does nothing on its own. It has to be explicitly configured to be useful, which is a detail worth confirming in a sandbox before assuming it is protecting anyone.

Rolling out the time entry duration controls without a mess

The temptation with either control is to set the value you actually want on day one: an 8 or 9-hour daily cap matching a standard workday, and a 15-minute increment matching your billing rate card. Resist that instinct for the first rollout cycle. Because validation runs on every create and modify, and because Project Operations time entry has several paths into the system beyond the standard weekly grid, including the Copy Week function, bulk import, and any canvas or model-driven app built against the time entry entity, a tight setting configured without a testing pass tends to surface every non-standard workflow your organization has quietly built up around timesheets.

A safer sequence starts with a maximum daily duration set deliberately loose, something like 16 or 18 hours, purely to catch the genuinely broken entries (the accidental 26-hour day, the decimal-point typo that becomes 240 hours) without touching resources who occasionally work a long day and log it honestly. Watch validation errors for a full billing cycle before tightening toward the actual policy limit. The minimum interval control deserves the same caution, but for a different reason: it will interact directly with any existing Power Automate flows, integrations, or import templates that write time entries with durations your organization never audited closely. An integration pulling hours from a separate scheduling or field service system, for instance, might write entries in whatever granularity that source system uses, and a newly enforced 15-minute increment will start rejecting them the moment it goes live. Map every system of record that writes into project time entries before you set this value, not after.

It is also worth coordinating both settings with how your organization has configured time zone behavior for the time entry grid. Project Operations lets teams choose between time zone aware date handling, where the same entry can display on different calendar dates depending on the viewer’s time zone, and time zone independent handling, which pins the date regardless of viewer location using a dedicated time zone independent date field. For a distributed delivery team spanning multiple time zones, a daily maximum duration check that is evaluated against a date that shifts depending on who is looking at it can produce validation behavior that looks inconsistent to end users, even though the underlying rule hasn’t changed. Confirm which time zone mode is active before assuming daily duration validation will behave the same way for every resource.

What these controls do not solve

Both features validate entries going forward. Neither one appears to retroactively flag or correct time entries that already exist in the system, so a backlog of historical bad data, the kind most organizations discover they have the first time they actually go looking, will not be swept up by turning either setting on. If a data cleanup is part of the motivation for adopting these controls, that remains a separate exercise, likely a Power Platform dataflow or a one-time script against existing records, not something the new parameters retroactively apply.

Equally, neither control replaces approval-stage review. A time entry that respects both the daily maximum and the minimum increment can still be entirely wrong: charged to the wrong project task, misclassified by type, or simply inaccurate about what work actually happened. Duration validation catches a narrow, specific class of error, the kind that shows up as an obviously implausible number or a fractional oddity, and it catches it earlier and more reliably than a human reviewer scanning a timesheet approval queue ever will. It is not a substitute for that review; it removes one category of noise so the review that remains can focus on judgment calls rather than arithmetic.

For organizations running Project Operations at scale, particularly those billing time-and-materials engagements where a single mis-keyed entry can mean a client invoice dispute, these two settings are a genuinely useful, low-effort addition to a governance model that most teams have historically had to build themselves. Getting the rollout sequencing right, testing against every system that writes time entries, and being honest about what the controls do not cover matters more than getting the exact numbers right on day one. Routeget Technologies has walked several Project Operations customers through exactly this kind of parameter rollout, and the pattern holds: the configuration itself takes minutes, and the discovery of what has been quietly writing non-compliant time entries into the system for years takes considerably longer.

#ProjectOperations #TimeEntryValidation #DynamicsFinanceOps #TimesheetGovernance #ERPDataQuality #PSAConfiguration

Direct Lake Semantic Models for Dynamics 365 F&O Data

BI developer reviewing a Direct Lake semantic model diagram for Dynamics 365 F&O data on a widescreen monitor

A BI developer at a manufacturing client rebuilt their Dynamics 365 Finance and Operations reporting as a Direct Lake semantic model the week Fast Fabric rolled out, expecting the same near-instant refresh everyone had been promised in the release notes. For the first ten days it worked exactly that way: framing updates that used to take an overnight BYOD job finished in seconds, and finance users watched inventory valuation numbers move in something close to real time. Then a month-end load pushed one fact table past a few hundred million rows, a refresh failed outright with no warning beyond a guardrail error code, and the model sat unqueryable until someone tracked down which table had tripped which limit. Nothing about Direct Lake had changed. What changed was that nobody had modeled for its ceilings before the data volume found them.

That gap between “Direct Lake is fast” and “Direct Lake behaves differently enough from Import mode that it needs its own design discipline” is where most F&O teams get tripped up right now. Fast Fabric has genuinely solved the latency problem that made near-real-time F&O reporting impractical for years, cutting sync times that used to run one to two hours down to under fifteen minutes in most observed cases, according to Microsoft’s own Dataverse and Fabric integration update. But building a semantic model on top of that faster pipe is a different exercise than plugging Power BI into a data warehouse, and the differences matter most exactly when a model is otherwise working well enough that nobody is looking closely at it.

BI developer reviewing a Direct Lake semantic model diagram for Dynamics 365 F&O data on a widescreen monitor

What actually lands in OneLake now

F&O data doesn’t write to OneLake directly. It flows through Dataverse, which is the layer that transforms F&O table data into Delta Parquet and exposes it to Fabric through shortcuts and mirroring, without the customer managing any Spark compute or Azure infrastructure themselves. That’s the architectural distinction from the older Synapse Link pattern, where a customer’s own Spark jobs did the transformation. Fast Fabric, now in public preview with global rollout completed and an automatic upgrade for existing customers planned for the first quarter of 2026, is what tightened the sync cadence on that same Dataverse-to-OneLake pipeline. Anyone still comparing today’s F&O-to-Fabric numbers against the old BYOD or Data Export Service benchmarks is working from a stale mental model of what the pipeline can do.

The practical consequence for a solution architect is that F&O tables show up in a Fabric lakehouse as Delta tables with a Dataverse-flavored schema underneath them: GUID-based keys, some binary columns, and complex types that don’t map cleanly onto every Direct Lake data type. That schema inheritance is the first thing worth checking before any modeling work starts, not after a refresh fails.

Choosing a Direct Lake semantic model: OneLake or the SQL analytics endpoint

Fabric currently gives two ways to put a semantic model directly on top of those Delta tables, and the choice isn’t cosmetic. Direct Lake on the SQL analytics endpoint reads through the lakehouse or warehouse’s SQL layer, supports non-materialized views, and, critically, falls back to DirectQuery automatically when a table can’t load in Direct Lake mode, for example when SQL-based row-level security is enforced. Direct Lake on OneLake skips that SQL layer and reads Delta tables directly from any Fabric source, which unlocks composite models that mix Direct Lake with Import or DirectQuery tables, calculated tables, and calculated columns (both still in preview and, for calculated columns, limited to user-context evaluation). The tradeoff is that Direct Lake on OneLake has no fallback path at all. If a query exceeds a guardrail, it fails. There is no quietly-slower DirectQuery safety net to catch it.

For most F&O reporting models, that argues for a specific default: use Direct Lake on OneLake when the model genuinely needs composite modeling or calculated tables over F&O data, and reach for Direct Lake on the SQL analytics endpoint when the model is closer to a straightforward reporting layer where a DirectQuery fallback is worth more than the extra flexibility. Architects who pick OneLake mode by default because it’s the newer, more capable option often find out about the missing fallback during a production incident rather than during design review.

Framing, transcoding, and what a guardrail failure actually costs

Direct Lake’s refresh model is fundamentally different from Import, and it’s worth explaining precisely because the difference is what makes the failure mode above so disruptive. A traditional refresh in Import mode copies the underlying data. Direct Lake framing copies only metadata: it analyzes the latest Delta table version, points the model’s references at the current files in OneLake, and finishes in seconds rather than minutes or hours. Data itself loads column by column, and only the columns a given query actually touches, through a process Microsoft calls transcoding. That’s what lets a Direct Lake model handle data volumes larger than a capacity’s memory ceiling; it never has to hold all of it at once.

Abstract visualization of real-time data synchronization from Dynamics 365 F&O into Microsoft Fabric OneLake

Capacity guardrails are what set the boundaries on this, and they scale meaningfully by Fabric SKU. An F2 through F8 capacity caps out at 1,000 Parquet files and 1,000 row groups per table, 300 million rows, and a 10 GB model size limit. Step up to F64 or above and those ceilings jump to 5,000 files, 5,000 row groups, and 1.5 billion rows, with model size effectively unlimited. A large F&O fact table, general ledger transactions or inventory movements on an enterprise instance, can realistically approach those lower-tier limits, which means the F-SKU a Fabric workspace runs on isn’t just a cost decision anymore. It’s a modeling constraint that should be checked against actual F&O table row counts before a Direct Lake model design gets finalized, not discovered when a guardrail breach takes the model offline.

The newer Manage Tables capability, now in public preview for existing Fabric links, gives architects a lever here that didn’t exist a year ago: selecting which F&O-sourced tables actually sync to Fabric, rather than replicating an entire dataset and hoping guardrails hold. Narrowing the synced table set to what a given semantic model actually needs is one of the more direct ways to keep a Direct Lake model inside its capacity’s guardrails without upgrading the SKU.

Data type conversions worth doing before, not after, deployment

Direct Lake doesn’t support every Delta data type. Complex Delta types, binary fields, and GUID columns need to be converted, typically to strings, before a Direct Lake model can use them cleanly. Because F&O data reaches OneLake through Dataverse’s schema, GUID-based surrogate keys and occasional binary fields show up more often than they would in a purpose-built warehouse schema, so this conversion step tends to hit F&O-sourced models harder than it hits models built from cleaner, purpose-designed lakehouse tables. Handling these conversions in a lakehouse notebook or a Fabric pipeline before the semantic model is built, rather than discovering the unsupported type at model creation time, avoids a rebuild cycle that’s easy to skip when a project is already behind schedule.

A few other constraints round out the pre-deployment checklist: Direct Lake has no gateway support, so on-premises data can’t participate directly; the semantic model’s workspace has to sit in the same region as the data source workspace; and Direct Lake isn’t available in personal workspaces at all. None of these are exotic edge cases for an enterprise F&O deployment, but each is the kind of thing that’s far cheaper to confirm during architecture review than to discover during a go-live weekend.

Building for the ceiling, not just the average day

Fast Fabric removed the latency excuse that used to justify slower, batch-oriented F&O reporting architectures, and that’s a real and welcome change. But a semantic model designed only against yesterday’s data volumes, without a look at capacity guardrails, fallback behavior, and the schema quirks Dataverse introduces, is a model that works fine until the month it doesn’t. Routeget Technologies has walked several clients through exactly this kind of pre-deployment guardrail check on F&O Direct Lake models, and the pattern holds: the projects that skip it don’t usually fail on day one. They fail on the first month-end close that actually stresses the numbers the design assumed would stay small.

#DirectLake #MicrosoftFabric #DynamicsFinanceOps #PowerBI #DataModeling #FabricGuardrails

Dynamics 365’s Tax Data Migration Tool: What Actually Gets Automated

Enterprise IT consultant reviewing tax configuration data on a monitor, representing Dynamics 365 tax data migration review

A solution architect I’ll call by his actual role, not his name, spent three weeks last spring rebuilding tax configuration for a distributor operating across six US states and two Canadian provinces. The client had outgrown the standard sales tax engine years earlier but never had a project sponsor willing to fund the rework. Every tax code, every group, every item tax group had to be re-created by hand in the newer Tax Calculation service, cross-checked against the original ledger parameters, and validated transaction by transaction. It was the kind of work nobody budgets enough time for, because on paper it looks like data entry, and it is exactly the work Microsoft’s new Tax Data Migration capability is now trying to automate.

That is the exact problem Microsoft is now trying to solve with a preview capability inside Globalization Studio called Tax Data Migration. Rather than asking implementers to rebuild tax master data from scratch, the tool reads a legal entity’s existing standard sales tax setup and generates a working Tax Calculation feature version automatically. It will not replace the judgment a migration still requires, but it does remove a meaningful share of the mechanical rebuilding that used to eat the first few weeks of every one of these projects.

What Tax Data Migration actually converts

The migration reads four categories of standard sales tax master data and maps each into its Tax Calculation equivalent. Sales tax codes become tax codes. Sales tax groups become tax groups. Item sales tax groups become item tax groups. And critically, the general ledger parameters that used to control cash discount and cash discount timing behavior get converted into tax jurisdiction parameters, since Tax Calculation manages that logic at the jurisdiction level rather than the ledger level.

The origin field on each tax code also gets translated rather than copied verbatim. A tax code set to calculate as a percentage of the gross amount becomes “By Gross Amount” in the new model; percentage of margin becomes “By Margin”; amount per unit becomes “By Quantity,” and so on through the six origin types the legacy engine supports. None of this is exposed as a simple lookup table in the product; it is worth documenting for your own project file before you run the migration, because a few of the mappings (particularly “percentage of sales tax” becoming “tax on tax”) are not intuitive if you have not seen the conversion logic before.

Abstract visualization of tax data migrating from one table structure to another in Dynamics 365 Finance

Where the automation gets genuinely clever, and where it gets messy

The part of this feature that will actually save implementation time is variant handling. In real tax configurations, the same tax code frequently shows up in multiple sales tax groups with different behavior attached, one group where it is marked exempt, another where use tax applies. The standard engine tolerates this because the group, not the code, carries the override. Tax Calculation does not work that way, so the migration tool automatically splits a conflicting code into variants: the original code keeps its name, and each subsequent variant gets a numeric suffix appended.

This is also where technical teams need to slow down before trusting the output. The suffix assignment order is explicitly documented as nondeterministic, meaning you cannot predict in advance whether a given tax group ends up with the base code or the _1 variant, and if the original code name is already at Tax Calculation’s ten-character limit, the tool truncates the base name to make room for the suffix. A code your team recognizes on sight can come out the other side looking different enough that a quick visual check will not catch a misassignment. Budget time to open every variant and confirm which tax group it landed in rather than assuming the naming is self-explanatory.

There is a harder stop worth planning around too. If the combined character length of the tax codes attached to a single tax group, or a single item tax group, exceeds 1,000 characters, the migration cancels outright with an error rather than producing a partial result. For a tax group used across many countries or with dozens of narrow tax codes attached, this is not a hypothetical edge case; it is the kind of limit that shows up on the first attempt for exactly the complex, multi-jurisdiction entities where the automation would otherwise save the most time. If you hit it, the fix is manual: trim the tax group before running the migration again, which somewhat defeats the point of automating the exercise for that entity.

The cash discount conflict nobody should skip

One behavior deserves specific attention because it fails silently in the sense that matters: the process still completes successfully even when it can’t fully reconcile a setting. If a tax group’s cash discount treatment differs from the general ledger default, the tool completes the migration and simply throws a warning naming the affected groups, leaving it to the implementer to go build the correct tax jurisdiction rule by hand afterward. It is easy to read a green completion status, skim past a warning banner, and move on to validation testing, especially on a project where the migration ran late in a sprint. Treat any cash discount warning as a required follow-up task, not an FYI, and reference Microsoft’s tax jurisdiction cash discount setup documentation directly rather than guessing at the intended rule from the original ledger parameter alone.

Scope limits that shape how you plan the work

Three constraints matter more for project planning than for the mechanics of any single run. First, the migration operates on one legal entity at a time, scoped to whichever entity is currently selected, so a multi-entity F&O implementation still needs a migration pass per entity rather than a single global conversion. Second, there is no incremental sync: if tax master data changes after you generate a feature version, those changes are not reflected automatically, and picking them up means creating a new version or rerunning the migration from the current state rather than patching the existing one. That makes sequencing important. Run the migration once your legacy tax setup is genuinely stable, not while a parallel project is still adjusting sales tax groups. Third, Brazil and India are explicitly excluded from the feature, which will matter for any global rollout that includes those entities; plan on manual configuration there regardless of how well the automation performs elsewhere.

Where this leaves an implementation plan

None of this changes the fundamental decision of whether to move to Tax Calculation, and it should not be read as a shortcut around understanding how applicability matrices, registration number rules, and jurisdiction-level parameters actually work in the target state. What it does change is where a project’s early hours go. Instead of spending the first several weeks re-keying tax codes and groups that already exist somewhere in the standard engine, a team can generate a starting configuration in an afternoon and spend the time it saved on the work that actually requires expertise: validating applicability logic, building jurisdiction rules for the edge cases the tool flags, and testing real transactions against the converted setup before it goes anywhere near production. The feature is still in preview with no announced general availability date, and Microsoft’s own documentation is explicit that preview functionality isn’t intended for production use, so the responsible move right now is to run it in a sandbox, learn where your specific tax configuration triggers variants or warnings, and have that homework done before GA arrives rather than starting from zero once it does.

We’ve run this migration path on sandbox copies of a few clients’ production tax configurations at Routeget specifically to build a checklist of the mapping quirks and character-limit failures worth watching for, and the pattern holds across fairly different configurations: the tool gets you most of the way to a working feature version, and the remaining ten percent is exactly the part that requires someone who understands both the old engine and the new one.

#TaxDataMigration #TaxCalculationService #GlobalizationStudio #DynamicsFinanceOps #ERPTaxCompliance #FinanceTransformation

Configuring Parallel Archive Processing in Dataverse Long-Term Retention

IT operations team reviewing data processing and capacity dashboards in a modern operations center

A solution architect running Dynamics 365 Finance and Operations across forty legal entities kicks off an archive job for General Ledger transactions on a Friday afternoon, then checks back a week later to find eleven entities still sitting in the queue. Each job runs start to finish before the next one begins, so a single line of sequential processing does all the work no matter how much idle capacity sits behind it. That queue is a direct consequence of how Archive with Dataverse Long-Term Retention was originally built: one job in flight per scenario, and everything else waits. Microsoft’s March 2026 private preview changes that constraint, and it does so through one new configuration concept worth understanding before requesting access: the job criteria key that makes parallel archive processing possible.

Why Dataverse Archive Jobs Queue Up Today

Archive with Dataverse Long-Term Retention moves data through three stages: active, historical but retained for compliance, and eventually deleted. Getting a record from the first stage to the second is a six-step background process: replication into Dataverse, marking the source record as eligible, updating its retention status, reconciling that the copy landed correctly, migrating it out of the live table, and finally exposing it to inquiry pages that can still read history. Depending on data volume, that full cycle runs seven to fourteen days, and it runs at a deliberately low priority so it doesn’t compete with transactional workloads during business hours.

The scenarios supported today span general ledger and tax transactions in Finance, inventory transactions, inventory journals, and sales orders in Supply Chain Management, and commerce transactions in Commerce, with more expected in future releases. None of that changes with parallel processing. What changes is how many of those seven-to-fourteen-day cycles a tenant can have running at once. Until this preview, the answer was one, regardless of whether an organization operates three legal entities or three hundred. A multi-entity deployment with a genuine general ledger archiving need could watch a backlog grow for months simply because the platform had no concept of running two independent jobs side by side, even when the two jobs touched completely unrelated data.

What Parallel Archive Processing Actually Requires

The mechanism Microsoft introduced is narrower than “run everything at once.” It hinges on a job criteria key, a partition identifier assigned when an archive job contract is created. When the scheduler sees two jobs with different criteria key values, it checks whether they target non-overlapping sets of records, and if they do, it lets both run concurrently instead of forcing the second to wait. If they don’t, or if the system can’t establish that they don’t, the original sequential behavior still applies.

That non-overlap condition is stated as an absolute in Microsoft’s own documentation: each job with a different criteria key value must process a completely distinct set of records, with zero overlap. There is no partial-credit version of this feature where jobs run concurrently and reconcile conflicts afterward. DataAreaId, the field that already partitions Finance and Operations data by legal entity, is the criteria key Microsoft is leading with in preview, and it’s an obvious starting point precisely because it satisfies that zero-overlap requirement by construction. Two legal entities never share a General Ledger transaction, so keying parallel jobs off DataAreaId is close to a free performance win rather than a configuration exercise with real risk attached, provided the archival scenario itself doesn’t reach across entity boundaries somewhere a solution architect hasn’t accounted for.

Solution architect reviewing a parallel data partition and processing pipeline diagram

Configuring the Job Criteria Key

The scenario itself doesn’t change; the contract does. When an archive job contract is created, the criteria key value is set alongside the usual scope of tables and date ranges, and it’s this value the scheduler reads to decide whether two in-flight jobs can share the pipeline. In practice, that means an implementation planning parallel General Ledger archiving across, say, twelve legal entities creates twelve contracts, one per DataAreaId value, rather than a single contract configured to somehow fan out internally.

Once jobs are running, the Archive with Dataverse Long-Term Retention workspace is where the criteria key earns its keep operationally. It surfaces each job’s key value alongside its status, so an administrator can confirm at a glance that the jobs actually running in parallel are the ones intended to run in parallel, rather than discovering after the fact that two jobs quietly targeted overlapping data. For organizations building custom archival scenarios against custom tables, the sequencing matters here specifically: those custom scenarios and their criteria key logic need to be defined and validated before the first parallel job runs against them, not adjusted afterward, because the zero-overlap guarantee has to hold from the first concurrent execution onward.

Where This Can Go Wrong

The zero-overlap requirement is also where the risk concentrates. A criteria key that looks like a clean partition on paper, a custom dimension that’s supposed to map one-to-one with a business unit, for instance, can turn out to have edge cases where two values legitimately touch the same record, particularly in customized environments where table relationships have been extended past their original design. Because the preview enforces zero overlap by requirement rather than by runtime detection of every possible conflict, the burden of proving that a custom criteria key is safe sits with the team configuring it, not with the platform.

Two other details are easy to miss because they don’t show up until after a job finishes. First, capacity reporting lags the actual archival work: history table capacity reductions from automatic tuning can take up to seven days to appear, and Dataverse’s own capacity figures take up to a day to catch up. Running four jobs in parallel instead of one doesn’t make that lag disappear, so finance and IT stakeholders expecting an immediate storage win on the day parallel jobs complete need that timeline set correctly in advance. Second, organizations that use customer-managed encryption keys should know that long-term retained data lands under Microsoft-managed keys regardless of how many jobs move it there in parallel, which means a CMK migration for that retained data is a separate project, not something parallel processing resolves as a side effect. Finance and operations attachments still aren’t supported in any configuration, and while data that hasn’t yet been archived can be handled through normal processes, data that has already made the trip into Dataverse long-term retention cannot be pulled back to live tables.

Piloting Before You Commit

Because this is a private preview, access starts with an enrollment request rather than a feature flag, and the honest advice for anyone requesting it is to have a specific backlog problem in mind rather than general curiosity about the feature. Organizations with dozens of legal entities and a General Ledger or inventory transaction archive that has been queuing for weeks are the clearest fit. A three-entity organization archiving a modest transaction volume is unlikely to notice much difference between sequential and parallel processing, since the queue was never the real bottleneck to begin with.

IT and finance team reviewing a data storage capacity and governance chart

Once enrolled, the safer rollout path is to pilot parallel jobs against two or three legal entities in a sandbox first, confirm through the workspace that the criteria keys behaved as expected and that no overlap issues or data inconsistencies surfaced, and only then scale up to the full legal entity list in production. Given that archived data can’t be moved back to live tables, a misconfigured criteria key is not a mistake worth discovering at production scale. Treat the capacity reporting lag and the CMK migration question as items to raise with finance and security stakeholders during that same pilot, not after the first production jobs complete, so nobody is caught explaining an unexpected reporting delay or an encryption gap after the fact. For organizations already running Archive with Dataverse Long-Term Retention against a multi-entity Finance and Operations deployment, this preview is worth requesting now. Routeget has been helping clients sequence long-term retention rollouts around exactly this kind of phased validation, and parallel archive processing is a natural next step for any environment where the backlog, not the archive design itself, has become the actual problem.

#DataverseArchive #ParallelProcessing #LongTermRetention #DynamicsFinanceOps #DataCapacityPlanning #CloudArchitecture

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

The AI Builder Copilot Credits Shift Is Rewriting Invoice Automation

Abstract visualization of an AI system extracting structured data fields from a scanned invoice, displayed on an office monitor

A Dynamics 365 Finance and Operations customer running automated AP invoice capture on AI Builder’s invoice processing model will not notice anything different on November 2, 2026. The flow will still trigger, the fields will still extract, and finance will still get its exception queue for anything below the confidence threshold someone set two years ago. What changes on that date is not the model. It is whether the credits paying for every one of those extractions still exist, and for a lot of organizations that built this automation quietly, without anyone tracking which license line item was actually funding it, the honest answer right now is that nobody knows.

Microsoft has been unwinding AI Builder’s original credit system since November 2025, when it stopped selling new AI Builder capacity add-ons, and the second half of what amounts to an AI Builder Copilot Credits transition lands on November 1, 2026: every seeded AI Builder credit bundled into Power Apps Premium, Power Automate Premium, and Dynamics 365 Finance and Operations licenses gets removed on that date. Copilot Credits take over as the funding mechanism going forward, and Microsoft has been explicit on one point: there is no automatic conversion. Whatever balance an organization is sitting on today does not roll into a Copilot Credits balance tomorrow. It has to be purchased separately, allocated deliberately, or the automation simply stops running.

Abstract visualization of an AI system extracting structured data fields from a scanned invoice, displayed on an office monitor

What Actually Sunsets, and What Doesn’t

It’s worth being precise about what this deadline touches, because the shorthand “AI Builder is going away” is wrong and it leads teams toward the wrong response. The invoice processing model, the document processing custom-model tooling, and the AI Builder connector actions inside Power Automate are not being retired. What’s ending is one specific funding source for them. Today, AI Builder actions in Power Apps and Power Automate draw first against AI Builder credits, whether that’s the 500 seeded into Power Apps Premium, the 5,000 in Power Automate Premium, or the 20,000 bundled into a Dynamics 365 Finance and Operations license, and only fall back to Copilot Credits once that pool is exhausted. After November 1, 2026, that first pool disappears entirely for anyone who hasn’t separately purchased an AI Builder capacity add-on before the cutoff, and Copilot Credits become the only meter running. Existing add-on holders get a longer runway, since those add-ons stay valid through their current contract terms even past the end-of-life date, but nobody can buy or renew one after November 1.

How the AI Builder Copilot Credits Rate Table Changes the Prebuilt-vs-Custom Decision

The part of this transition technical teams should actually care about isn’t the deadline itself, it’s the pricing structure underneath it, because it quietly resolves a tradeoff a lot of architects have been living with for years. Under the legacy AI Builder credit system, running a page through the prebuilt receipt or invoice model cost 32 credits, while running that same page through a custom-trained document processing model cost 100 credits, roughly three times as much. That gap pushed a lot of implementations toward the prebuilt invoice model even in cases where a custom model, trained on one vendor’s actual invoice layout, would have extracted fields more reliably. Under Copilot Credits, both capabilities are priced identically at 8 credits per page. The three-to-one penalty for training a custom model is gone.

That’s a real architectural decision point, not a footnote. If an AP automation pipeline has been leaning on the prebuilt invoice model and routing a meaningful share of extractions to manual review because one vendor’s layout doesn’t match the model’s expectations well, whether that’s multi-column line items, remittance details in an unusual spot, or a logo block that confuses the header fields, it’s worth revisiting whether a custom collection trained on that vendor’s actual documents would now clear review automatically instead. The cost argument that used to say no has mostly disappeared, and for high-volume vendors specifically, the accuracy gain from a purpose-trained model can be worth the labeling effort even before factoring in the credit parity.

Reconfiguring the Flow Itself

For teams staying on the prebuilt path, the “Extract information from invoices” action inside the AI Builder connector remains the fastest route to a working pipeline. It returns more than forty fields: invoice ID, vendor name, purchase order, subtotal, tax, and total among them, each in both a raw text form and a standardized number or date form. The standardized fields are the ones worth wiring into a Business Central or F&O AP posting call; the raw text versions exist mainly for audit trails and for surfacing to a human reviewer. Every field also carries its own confidence score between 0 and 1, and the model doesn’t enforce a threshold on your behalf, so that logic has to live in the flow itself. Anything below roughly 0.8 confidence, a starting point worth tuning against your own vendor mix rather than treating as gospel, should route to an approvals step instead of posting automatically. One configuration detail trips up new implementations more than any other: the page-range parameter needs to isolate exactly one invoice per extraction call. Feeding it a multi-invoice batch PDF and letting it run across every page returns fragmented, unusable data, so any intake process that scans a stack of invoices into a single file needs a splitting step before the AI Builder action ever runs.

Solution architect reviewing an automation pipeline diagram and scanned document previews on dual monitors

For teams building or reconsidering a custom document processing model given the new pricing, a few practical constraints are worth knowing before starting. Microsoft’s own guidance puts five documents as the technical minimum to train a collection, but fifteen to twenty is what actually produces usable accuracy, and that number climbs further when the source scans are lower quality. Each collection needs a single, consistent layout, which means a vendor sending three different invoice templates needs three separate collections rather than one, and a model can hold up to 200 collections, generous enough to cover a large and varied vendor base once the labeling work is done properly. High-volume AP operations should also plan around the platform’s processing ceiling of 360 documents per environment every 60 seconds; a month-end batch run that dumps thousands of invoices into a flow all at once will hit that limit and needs to be throttled or staggered rather than fired in a single burst.

Budgeting the Migration Before the Deadline

The practical work between now and November 1 starts with knowing what’s actually being consumed today. The AI Builder Consumption Report in the Power Platform admin center breaks usage down by environment, day, and user, and it’s the fastest way to find out whether a given AP automation flow is currently riding on seeded Dynamics 365 credits, a Power Automate Premium allocation, or an add-on nobody quite remembers purchasing. That figure, recalculated against Copilot Credit rates rather than legacy AI Builder credit rates, is the real basis for a Copilot Credits purchase, not a guess pulled from a vendor conversation. It’s also worth checking whether credits have already been allocated to specific environments in the admin center, because once an environment has an allocation, it only draws against that allocation. There’s no automatic fallback to a tenant-wide pool if it runs dry, which means a production AP flow deserves its own guaranteed allocation rather than sharing an unassigned pool with every sandbox and test environment in the tenant.

The failure mode is also worth testing deliberately rather than discovering it in production. When both AI Builder and Copilot Credits are exhausted, the action doesn’t degrade gracefully; it returns an EntitlementNotAvailable or QuotaExceeded error and the flow run fails outright. For an AP pipeline finance depends on to keep invoices moving, that’s a materially different failure than a low-confidence extraction routed to manual review. It’s a stalled queue with no automatic recovery path until someone notices and tops up credits. Building an explicit fallback now, an error-handling branch that logs the failure and alerts AP operations rather than letting the flow simply stop, is a small addition that avoids a genuinely disruptive incident in November.

None of this is a reason to walk away from AI Builder-based invoice automation, and the pricing shift actually opens up a better architecture for organizations that outgrew the prebuilt model years ago but never revisited the decision. It does mean the flows can’t keep running unattended the way they may have since they were first built. Anyone operating AP automation on this stack should treat the next several weeks as a genuine architecture review rather than a routine licensing renewal, and organizations that have worked through document capture pipelines like this with clients, Routeget Technologies among them, tend to find the credit math is rarely the hard part. It’s the vendor-layout audit and the fallback handling that actually takes the time.

#AIBuilder #CopilotCredits #PowerAutomate #InvoiceAutomation #DynamicsFinanceOps #EnterpriseAI