Business Central CAMT.053 Migration: What Actually Needs to Change

Finance professional reviewing bank reconciliation data on a desktop monitor in a modern office

A finance systems administrator at a mid-size manufacturer got an email last month from the company’s German house bank. Starting in the first week of the new quarter, the daily MT940 statement feed that had fed Business Central’s bank reconciliation for six years would stop. In its place: a CAMT.053 XML file, delivered on a different schedule, with a different structure. The email asked, almost as an afterthought, whether the ERP would “just work” with the new format. It was not a rhetorical question the bank expected an answer to. It was a notice.

That conversation is playing out across Business Central shops right now, and it is worth understanding why the Business Central CAMT.053 migration is arriving in 2026 specifically, what Business Central’s native tooling actually does with a CAMT.053 file, and where that tooling quietly runs out before a consultant finds out the hard way during a month-end close.

Finance professional reviewing bank reconciliation data on a desktop monitor in a modern office

Why the Business Central CAMT.053 Migration Is Landing Now

The ISO 20022 migration has two distinct halves, and they are not moving on the same clock. The first half concluded in November 2025, when SWIFT ended coexistence for cross-border payment instructions. MT103, MT202, and the rest of the legacy payment message types stopped flowing in their original form; everything now moves as ISO 20022 MX, primarily pacs.008 and pacs.009. Institutions that kept sending legacy MT payment formats after that date found them auto-converted by SWIFT, with additional charges applied starting January 1, 2026.

The second half, covering statement and reporting formats rather than payment instructions, was deliberately left on a slower and less coordinated timeline. MT940 and MT950 (account statements), MT900 and MT910 (debit and credit notifications), and MT941 and MT942 (intraday reporting) are being replaced by camt.053, camt.054, and camt.052 respectively, but SWIFT is not converting MT9xx traffic to camt format automatically. Each bank negotiates its own cutover, account by account, on whatever internal schedule its own core banking migration allows. That is precisely why one Business Central customer converted a year ago without much drama, another is getting the notice this quarter, and a third will not hear anything until 2027. There is no single migration date to plan around. There are dozens of them, one per banking relationship, arriving on nobody’s schedule but the bank’s.

The Business Central Side of the CAMT.053 Migration

Business Central handles SEPA CAMT import through a Data Exchange Definition, a mapping layer that translates XML element paths in the bank’s file into fields across three tables: the General Journal table, the Bank Acc. Reconciliation header, and the Bank Acc. Reconciliation Line table. The mapping itself is fairly mechanical once you see it laid out. The transaction amount and its sign come from Stmt/Ntry/Amt combined with the credit or debit indicator at Stmt/Ntry/CdtDbtInd, with a configurable negative-sign identifier (typically set so that DBIT entries post as negative). Posting and transaction dates come from Stmt/Ntry/BookgDt, which can arrive as either a plain date or a full timestamp; Business Central accepts both. Payer information for matching comes from Stmt/Ntry/NtryDtls/TxDtls/RltdPties/Dbtr/Nm, and the free-text remittance information that drives most of the automatic matching logic comes from Stmt/Ntry/NtryDtls/TxDtls/RmtInf/Ustrd.

The field that actually determines whether any of this works is easy to miss: Stmt/Ntry/NtryDtls/TxDtls/Refs/EndToEndId. This is the identifier Business Central relies on to treat each line as unique within an open reconciliation. If a bank’s first-generation camt.053 export leaves this element empty, or populates it with a placeholder value repeated across an entire batch, the failure mode is not an import error. The file parses without complaint. What actually happens is worse in a subtler way: lines with a missing identifier get silently dropped, and lines that share a duplicated identifier with something already posted will import but fail automatic matching one by one, with no message pointing back to the cause. A team that has not specifically gone looking for this will spend a reconciliation cycle assuming the new statement format is simply less complete than the old one, when the real problem is a configuration gap that a five-minute look at the raw XML would have caught before go-live.

Abstract visualization of two data streams merging, representing a bank statement format migration

Where the Generic Definition Runs Out

Business Central ships a generic SEPA CAMT data exchange definition, and it is a reasonable starting point, not a finished solution. CAMT.053.001.08 is a schema, not a single fixed file layout, and individual banks populate it with their own dialect: some banks include optional elements Business Central’s default mapping ignores, some omit fields the default mapping expects, and namespace versions drift between institutions even within the same country. In practice, most multinational Business Central deployments end up cloning the generic definition per banking relationship rather than trying to maintain one shared version that quietly breaks every time a new bank is onboarded with slightly different habits.

It also helps to be honest about geographic scope. CAMT adoption is heavily concentrated in the EU and a handful of other markets that have committed to the SEPA-aligned schema. Plenty of banks elsewhere, particularly smaller regional institutions in North America and parts of Asia, are staying on BAI2 or proprietary flat-file formats for the foreseeable future, with no camt.053 timeline at all. A single Business Central tenant with entities in four countries can easily end up running MT940, camt.053, and BAI2 in parallel for years, not as a transitional state but as the normal operating condition. For organizations with a long tail of smaller regional banking relationships, this is where an ISV connector such as AMC Banking 365 Fundamentals earns its licensing cost: it converts against several hundred bank-specific format variants through its own service rather than asking an internal team to build and maintain a bespoke Data Exchange Definition for every regional bank quirk. That trade-off is worth evaluating deliberately, since routing statement data through a third-party conversion service is a data-governance decision as much as a technical one.

A Practical Migration Checklist

The teams that get through a bank-driven format change without a rough reconciliation cycle tend to do a few things in a specific order. They start by inventorying every bank account’s current import format code and confirming the actual cutover date per relationship, since assuming all banking relationships move together is the single most common planning mistake. Before the cutover, they request an actual test camt.053 file from the bank, not a sample pulled from vendor documentation, and run it through the Data Exchange Definition in a sandbox company where a bad mapping does no damage. They open that test file as raw XML and check the EndToEndId population line by line rather than trusting that because a mapping worked for one bank’s camt.053 export, it will behave identically for another bank using the same nominal schema version. Where any deviation shows up, they clone the generic SEPA CAMT definition into a bank-specific version rather than editing the shared default, so a fix for one relationship cannot silently change behavior for every other bank account using the same code. They keep the outgoing MT940 or BAI2 definition active and assigned for as long as the bank is willing to run both feeds in parallel, because a same-day cutover with no fallback window turns any mapping problem into an immediate reconciliation gap. And before retiring the old feed for good, they re-test automatic matching rates against a full month of real transaction volume on the new format, since a quiet drop in match percentage is a far more reliable early warning of a mapping issue than an outright import failure would be.

What Copilot’s Bank Reconciliation Assist Does and Doesn’t Solve Here

Business Central’s Copilot-assisted bank reconciliation feature, currently in preview, is genuinely useful for what it does: it analyzes unmatched transaction descriptions and ledger entries to suggest matches and likely G/L accounts, including scenarios where a single deposit needs to be split across several invoices. It is worth being clear about its boundaries in this specific context, though. It operates entirely downstream of the Data Exchange Definition, on statement lines that have already been successfully parsed into the system. If a mapping problem is dropping or mismatching lines before they ever reach the reconciliation worksheet, no amount of AI-assisted matching afterward will surface or correct that. The feature also performs best when transaction descriptions and G/L account names share a single consistent language, which is worth double-checking specifically during a format changeover, since a bank’s new camt.053 export sometimes reformats descriptive text differently than its old MT940 feed did.

The Deadline Is the Bank’s, Not Yours

None of this is a discretionary upgrade a Business Central team can schedule around a quieter month. It is a mapping and validation project with a deadline set by someone else’s core banking migration, arriving on a per-relationship basis rather than a single company-wide date. The organizations handling it well are the ones treating each bank’s cutover notice as a trigger for testing, not as an announcement to file away until the old feed actually stops. Routeget has walked several clients through exactly this kind of parallel MT940 and camt.053 coexistence during multi-entity rollouts, and the pattern is consistent: the mapping work is small, but only when someone does it before the bank forces the issue rather than after.

#BusinessCentral #CAMT053Migration #BankReconciliation #ISO20022 #DataExchangeDefinitions #ERPIntegrations

The Warehouse App V3 to V4 Migration Is an Infrastructure Project, Not an App Update

Warehouse worker scanning a barcode with a handheld mobile device in a distribution center

A distribution center running a fleet of Zebra handhelds on the Warehouse Management mobile app got a call from the floor supervisor in late July: barcode scans on inbound receiving were suddenly failing on about a third of devices, right after an over-the-air Android update pushed through despite the fleet being enrolled in Intune with update deferrals configured. The IT team opened a support ticket. The answer that came back wasn’t a patch. It was a reminder that the app on those devices, version 3, had been out of support since May, and the fix wasn’t going to be a hotfix to V3. It was going to be the V3 to V4 migration the team had scheduled for “sometime in Q3” and then quietly let slide.

That scenario is playing out at more distribution operations than Microsoft’s release notes would suggest, because the framing around this migration has made it sound smaller than it is. Under the hood, this isn’t a UI refresh. Microsoft rebuilt the Warehouse Management mobile app from scratch, moving it off Xamarin, a framework Microsoft itself retired from general support back in 2024, and onto React Native. That single architectural fact explains almost everything else about why this migration behaves differently from a normal app update, and why solution architects planning a fleet rollout need to treat it as an infrastructure project rather than an app-store bump.

Why This Isn’t a Simple App Update

Xamarin’s own end of life is the real driver here, not a desire to add dark mode. A framework built on Mono and .NET for cross-platform mobile development, Xamarin stopped receiving Microsoft support in May 2024, which put every product still built on it, including the warehouse app, on a clock. React Native gets Microsoft a modern, actively maintained foundation, and it shows up concretely in the release cadence: since V4’s staged rollout completed in early 2026, point releases have shipped roughly monthly, each carrying real functional changes rather than just security patches.

The rewrite also changed the authentication stack, replacing legacy libraries with MSAL and OneAuth, and that change has consequences that have nothing to do with barcode scanning. On Windows, the redirect URI registered in Azure AD app registrations needs to include ms-appx-web://microsoft.aad.brokerplugin/{clientId} for the broker flow to work. For on-premises deployments authenticating through AD FS, both Windows and Android need new redirect URIs registered before a single device can sign in to V4, which means this migration touches identity configuration owned by a different team than the one running the warehouse floor, and that handoff is where a lot of rollouts stall.

Abstract visualization of a mobile device platform migration on a handheld scanner screen

What Actually Breaks During a V3 to V4 Migration

Three things trip up fleet migrations that the high-level release notes gloss over, and all three are worth budgeting time for before a rollout window opens rather than during it.

The first is device eligibility. V3 supported Android 5 and later, while V4 requires Android 7. Any handheld still running Android 5 or 6, which is not unusual in a warehouse fleet with a five-to-seven-year hardware refresh cycle, simply cannot run V4 and has to keep running V3 until it’s replaced. That forces a mixed-fleet reality during the transition window: V3 and V4 can run side by side on different devices without conflict, but they cannot coexist on the same device, so the migration has to be planned and executed per device, not as a single global cutover.

The second is the iOS experience, which behaves noticeably worse than Android or Windows during migration. On those two platforms, connection settings carry over automatically from V3 to V4 as long as the device was already on V3 version 3.0.8 or later before the switch. On iOS, none of that carries over. Every connection has to be manually reconfigured after installing V4, and Device Code authentication, which a lot of iOS deployments relied on, isn’t supported in V4 at all; iOS is limited to username and password. The practical workaround worth building into a migration plan is generating QR codes or JSON configuration files ahead of time for each site or device group, so floor staff aren’t hand-typing server URLs and warehouse codes on a phone screen during a go-live window.

The third is the support-window structure itself, which changed again after V4 launched. Starting with version 4.1.1.0, Microsoft introduced a rolling twelve-month support window, effective May 2027, meaning only V4 releases published within the previous twelve months are eligible for support at any given time. A fleet migrated to V4 in early 2026 and left untouched will fall out of that support window well before 2027 arrives, so the actual deliverable of this project isn’t “get to V4.” It’s “get to V4 and keep a patch cadence going,” which is a different kind of ongoing commitment than most IT teams budget for an app migration.

A Practical Migration Sequence

The sequence that has worked cleanly across the fleet migrations worth learning from starts with an inventory, not an install. Pull every device’s current OS version and current app version before scheduling anything, because that inventory determines three separate migration paths: devices already eligible for direct upgrade, devices that need a V3 update to 3.0.8 or 3.0.9 first to preserve their configuration, and devices that need hardware replacement before they can run V4 at all.

For the Android and Windows devices in the first two paths, the upgrade itself is close to routine: push the V4 install through Intune or another MDM tool without uninstalling V3 first, since choosing the in-place upgrade path is what preserves the existing connection settings. Stage this in waves by site or by shift rather than as a single fleet-wide push, because the one-time reauthentication requirement per device means a help desk fielding sign-in questions from three hundred devices simultaneously is a bad night for everyone involved, whereas fifty devices at a time is manageable.

For iOS, treat it as its own project inside the larger migration rather than an afterthought. Confirm every affected user has username and password credentials provisioned before the cutover, since Device Code won’t be available as a fallback. Build the QR code or JSON configuration files in advance, and consider disabling auto-update on iOS devices until those configuration artifacts are ready, so a device doesn’t land on V4 mid-shift with no way to reconnect.

Keep the rollback path in mind but don’t lean on it as a safety net for the whole fleet. Individual devices can be downgraded to V3.0.9 if V4 surfaces a blocking issue during testing, which is useful for a pilot group, but Microsoft has been clear that once a region has fully migrated, that region-level rollback isn’t available. Pilot on a genuinely small, representative slice of the fleet, not just the devices sitting on IT’s desk.

Closing the Loop After Go-Live

The migration doesn’t end when the last device reports in on V4. Recent point releases have shipped capability that’s worth actively adopting rather than ignoring once the fleet is stable: a ProGlove arm scanner bridge for hands-free scanning workflows, editable client settings that let enterprise environments enforce TLS 1.2 and forced sign-in policies centrally, and expanded barcode format support including GS1 batch number separators that some receiving workflows depend on. None of that shows up automatically; it requires staying inside that rolling twelve-month support window Microsoft built into the V4 support model, which means assigning someone ownership of the update cadence the same way a team would own patch management for any other production system.

Routeget has run this exact device-inventory-first sequencing for several clients moving mixed Android and iOS fleets this year, and the pattern holds: the migration itself is mechanical once the inventory and identity prerequisites are sorted out. What actually determines whether it goes smoothly is whether someone treated it as an ongoing operational commitment from the start, rather than a one-time app-store update to check off a list.

#WarehouseManagementApp #DynamicsSCM #MobileFleetMigration #XamarinToReactNative #ERPGovernance #SupplyChainAutomation

Advanced Connector Policies Are GA. Here’s What Still Needs Classic DLP.

IT governance administrator reviewing a Power Platform connector policy dashboard on a widescreen monitor

An admin at a 400-environment tenant spent a Tuesday afternoon tracing why a maker in a finance sandbox could connect a flow to a third-party file-sharing connector that should have been blocked tenant-wide. The tenant-level DLP policy classified the connector as non-business. An environment-specific policy, created eighteen months earlier for a since-retired pilot project, had it classified as business instead, and because classic DLP evaluates every applicable policy and merges the results, the older, looser rule won for that one environment. Nothing was misconfigured in the sense of a typo or a missed checkbox. It was misconfigured in the sense that nobody could reason about which rule applied where anymore.

That kind of drift is the specific problem Advanced Connector Policies were built to close, and as of June 4, 2026, they are generally available across the Power Platform admin center. For solution architects and platform administrators who have spent years managing DLP through the classic business/non-business/blocked model, ACP is not a UI refresh. It changes the underlying enforcement model, and it does not yet cover everything classic DLP does, which means the real work right now is figuring out exactly where the boundary sits.

What Advanced Connector Policies Actually Change

Classic DLP lets an environment inherit from multiple overlapping policies at once: a tenant-wide baseline, group-level rules, environment-specific exceptions, sometimes all three stacked on top of each other. The runtime evaluates all of them and applies the most restrictive result for a given connector, which sounds safe until you have dozens of overlapping policies and nobody has a single view of what’s actually allowed in environment 214. Advanced Connector Policies replace that model with something much narrower: each environment can have exactly one effective ACP, either configured directly on the environment or inherited from an environment group, never both at once.

The more consequential change is the default posture. Classic DLP sorts connectors into three buckets and anything not explicitly sorted lands in a default bucket, which in practice means most connectors are reachable unless someone deliberately restricts them. ACP inverts that. It is a strict allowlist: every connector is blocked until an administrator explicitly allows it, and critically, newly released connectors are blocked by default rather than automatically available. That second part matters more than it looks. Under classic DLP, Microsoft ships a new certified connector and it’s immediately usable in every environment that doesn’t have an explicit block rule against it, which is exactly how ungoverned tools accumulate over time. Under ACP, a new connector requires deliberate action before anyone can touch it, which shifts the operational model from periodic cleanup to ongoing curation.

Action-Level Control and Where MCP Governance Fits

ACP also goes deeper than connector-level allow or block. Within an allowed connector, admins get visibility into individual triggers, regular actions, internal actions, and actions Microsoft has marked deprecated, and can block any of those independently, which is useful for pushing makers off a deprecated action a legacy flow still references without pulling the whole connector. One behavior worth knowing before you rely on it: once a connector is scoped down to specific allowed actions, any new action or trigger Microsoft adds later isn’t automatically included. It has to be added deliberately, consistent with the allowlist philosophy but meaning a connector configured carefully in June can quietly miss a capability Microsoft ships in September until someone revisits the policy.

IT governance administrator reviewing a Power Platform connector policy dashboard on a widescreen monitor

This is also where ACP intersects with agentic AI governance, worth calling out since most classic DLP writeups predate MCP entirely. Advanced Connector Policies give admins visibility into MCP servers alongside standard connectors and let them block an entire server, but they don’t yet offer granular control over individual tools exposed by that server. If a team stands up an MCP server bundling a dozen tools and you need eight of them permitted while two are blocked, ACP can’t currently express that: the block is server-wide or nothing. For organizations moving quickly on Copilot Studio agents and custom MCP integrations, that’s a real gap to plan around, since it means governance over agent tool access is currently coarser than governance over a standard connector’s actions.

What’s Still Missing, and Why Classic DLP Isn’t Going Away Yet

The limitation that will affect the most environments in practice is that ACP currently only governs certified connectors. Custom connectors and HTTP connectors, including HTTP with Azure AD and the endpoint filtering that lets admins restrict a custom or HTTP connector to a specific allowed URL pattern, are not supported in ACP today and have no committed timeline for parity. If your tenant relies on endpoint filtering to say, for instance, that a generic HTTP connector may only call approved internal APIs and nothing else, that control still lives entirely in classic DLP. Virtual connectors are a separate case again: Copilot Studio’s virtual connectors are being moved to a dedicated governance model built specifically for that surface rather than folded into ACP, and Power Automate desktop flow virtual connectors are being converted into certified connectors over time, at which point they’ll fall under standard ACP rules like anything else.

Microsoft’s answer to this gap is mixed mode, which is also the default state for any environment or environment group where ACP has been configured. In mixed mode, both classic DLP and ACP evaluate simultaneously and the platform applies whichever result is more restrictive. That’s a genuinely useful design for migration: an organization can build out its ACP allowlist for certified connectors incrementally, watch how it behaves in mixed mode against real usage for a few weeks, and keep the existing classic policy doing the work ACP can’t do yet, namely custom connectors, HTTP endpoint filtering, and virtual connectors. Only once an environment’s governance needs are fully expressible in ACP, which for most tenants means never for HTTP-heavy environments, should it be switched to ACP-only mode, which turns off evaluation of classic policies entirely for that scope and can only be reversed by reconfiguring the rule.

Abstract network diagram on a laptop screen showing allowed and blocked system connections

Design-Time Enforcement Is Rolling Out Workload by Workload

One detail that’s easy to miss in the announcement is that GA for ACP as a policy engine is not the same as GA for design-time enforcement across every maker surface. Design-time blocking, meaning a maker sees an error while building a flow or app rather than discovering the failure at runtime, is rolling out one workload at a time: Power Automate’s maker portal first, Copilot Studio next, and Power Apps’ maker portal after that. Until a given surface has design-time support, ACP still enforces at runtime there, which means a maker in Power Apps today can build and save a canvas app referencing a blocked connector and only find out it doesn’t work when the app actually runs. That’s a materially different experience from the flow-checker warning a Power Automate maker gets today, and it’s worth setting expectations accordingly with any citizen developer population still working primarily in Power Apps.

A Practical Migration Sequence

The organizations getting this right aren’t treating ACP as a lift-and-shift replacement for their existing DLP policy set. They start with an audit of what their current classic policies actually enforce, separating that into a certified-connector allowlist that can move to ACP and a residual set of custom-connector, HTTP endpoint-filtering, and virtual-connector rules that has to stay in classic DLP indefinitely. From there, building the ACP allowlist environment-group by environment-group, publishing it in mixed mode, and giving it real usage time before considering ACP-only mode avoids the failure pattern of flipping a switch tenant-wide and finding the gaps through a flood of support tickets. It’s also worth reconciling allowed-connector lists periodically through the Power Platform API rather than the admin UI alone, since retired or invalid connector IDs accumulate in a policy’s configuration and throw off the connector count the UI reports without actually blocking anything.

One operational gotcha worth flagging before it surprises anyone: removing an ACP rule from an environment group does not automatically remove that policy from environments that already inherited it, and removing an environment from a group retains whatever ACP configuration it last had rather than reverting to unrestricted. That’s a deliberate design choice to prevent a connector from becoming unexpectedly available during a reorganization, but it means offboarding an environment from group-based governance requires an explicit cleanup step, not just a drag-and-drop out of the group.

None of this makes classic DLP obsolete, at least not on any announced timeline, and treating ACP’s June GA as a mandate to migrate everything immediately would be a mistake for any tenant with meaningful HTTP or custom connector usage. What it does change is the ceiling on how precisely certified-connector access and AI agent tooling can be governed, and for tenants running large numbers of managed environments, that precision is the difference between a policy set someone can actually audit and one that quietly drifts for eighteen months until an admin loses an afternoon tracing it. We’ve walked several clients through exactly this audit-first sequencing this year, and the pattern holds regardless of tenant size: know what you’re moving before you touch the switch.

#AdvancedConnectorPolicies #PowerPlatformGovernance #DataLossPrevention #MCPGovernance #ConnectorSecurity #EnterpriseAI

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

The Power Pages Security Model Is Changing. Your Table Permissions Still Need an Audit.

IT security professional reviewing an abstract portal permissions and access-control dashboard on a widescreen monitor

A CIO at a mid-size insurer found out about the problem during a routine vendor risk review, not from an internal alert. A claims-intake portal built two years earlier by a business analyst on the operations team, using Power Pages because it was faster than waiting for a developer sprint, had an Anonymous Users role configured with Global Access read permission on a table that included policyholder contact information. Nobody had touched the site’s permissions since launch. Nobody on the security team had reviewed it either, because it had never appeared on a list of applications anyone was tracking. That is the quiet risk of low-code external portals: they get built quickly, they work, and they slip out of the governance perimeter that would normally catch a misconfiguration like this one. It is also the backdrop against which every CIO should be reading Microsoft’s current overhaul of the Power Pages security model, because the two changes underway solve different halves of that same problem.

This is not a hypothetical. In late 2024, researchers at AppOmni disclosed that a large number of Power Pages sites across industries, including a UK National Health Service contractor, were exposing sensitive data because of exactly this pattern: table permissions granted at Global Access to the Anonymous Users or Authenticated Users role, on sites where self-registration meant “authenticated” effectively meant “anyone who signed up.” One case alone reportedly exposed contact information for more than a million people. Microsoft’s own documentation on table permissions has warned about this since Power Pages existed under its earlier name, but the setting is easy to get wrong and easy to forget about once a site is live.

Two Different Problems Wearing the Same Name

Microsoft’s response to date has taken two distinct forms, and it is worth CIOs and IT directors being precise about which one solves which problem, because the two get conflated in vendor briefings more often than they should.

The first is a genuine security tool: the Security Scan and Security Hub capability, which reached general availability in the back half of 2025. It scans a site’s configuration and flags the exact patterns AppOmni’s researchers were finding by hand, such as Anonymous or Authenticated roles with unusually broad table access. This is the tool that actually catches the problem described above, and if your organization has Power Pages sites in production and has not run this scan against every one of them, that is the first governance action to take this quarter, independent of anything else in this article.

Abstract close-up of a laptop screen showing a glowing network authorization diagram with role and permission nodes

The second is architectural, and it is easy to mistake for a security fix when it is really a plumbing change. Power Pages has always run two separate authorization systems side by side: Web Roles, which govern what a portal visitor can see and do on the site itself, and Dataverse Security Roles, which govern access to the underlying data. They were related but not unified, which meant a portal’s activity in Dataverse was historically attributed to a shared application user rather than the individual who was actually signed in, and administrators had to document, reason about, and troubleshoot two parallel permission models for the same site. Starting with a preview that shipped July 8, 2026 and targeted for general availability in November 2026, Microsoft is merging the two: each Power Pages user is now represented as both a Dataverse Contact and a Dataverse System User, and each Web Role maps directly to a corresponding Security Role. When a portal visitor calls Dataverse, the request now carries that visitor’s own identity rather than a generic service account.

What Changes in the Power Pages Security Model, and What Doesn’t

For a CIO evaluating whether this matters, the honest answer is that it is a governance quality-of-life improvement, not a vulnerability patch. The practical benefits are real but specific. Audit trails improve meaningfully, because actions taken through a portal now show up in Dataverse tied to the actual visitor rather than a shared identity, which matters for any organization that has to answer a compliance question like “who accessed this record and when.” Administrative overhead drops somewhat, because a security team no longer has to maintain a mental model of two loosely coupled permission systems and explain the seams between them to auditors or new hires. And because Microsoft describes this as a structural consolidation rather than a breaking change, existing sites are not expected to require a manual permissions migration when the rollout reaches them.

What it does not do is retroactively fix an Anonymous role that already has Global Access to a sensitive table, add column-level masking to a site that never configured it, or catch a wildcard entry in a site’s Web API field allowlist. Those are governance decisions, made by whoever configured table permissions when the site was built, and they persist through the unification exactly as they were. A cleaner, more auditable authorization backbone makes it easier to see a bad permission grant once someone goes looking for it. It does not go looking on its own.

What This Means for the Portal Sitting in Your Environment Right Now

If your organization has any Power Pages sites in production, three actions are worth taking before the November GA date, not because the unification itself is risky, but because it is a natural forcing function to finally do the review that should have happened at launch.

Start with an inventory question that is more often skipped than answered: does IT actually have a current list of every Power Pages site running in the tenant, who built it, and what data it touches? Citizen-developer tools succeed precisely because they let business teams build without waiting on IT, which also means those teams do not always think to tell IT what they built. A Power Platform Center of Excellence setup, or even a simple quarterly export from the admin center, closes this gap cheaply.

From there, run the Security Scan against every site on that list and treat any Global Access finding on the Anonymous or Authenticated role as a same-week fix, not a backlog item. Pair that with a manual check the automated scan will not catch on its own: whether column-level security profiles are configured on any table that includes personally identifiable information, since AppOmni’s testing found this control essentially unused across every site they reviewed, scanned or not.

Finally, treat the unification’s traceability improvement as an opportunity rather than a compliance checkbox. Once portal actions in Dataverse are attributed to individual users instead of a shared application identity, that data becomes genuinely useful for security operations and for internal audit, but only if someone owns pulling and reviewing it. Assign that ownership now, while the change is still new, rather than assuming a dashboard will surface it automatically.

We have run this exact audit sequence, security scan first, then a manual table-permission and column-security review, for several clients ahead of their own Power Pages authorization changes this year, and the pattern holds every time: the sites that fail are the ones nobody had looked at since the day they launched. A consolidated security model makes that oversight easier to catch. It does not make it disappear on its own, and the organizations that treat the two as the same thing are the ones that will still be explaining an exposure to their board next year.

#PowerPages #PowerPlatformGovernance #DataverseSecurity #CitizenDevelopment #DataProtection #DigitalTransformation

Sales Opportunity Agent Risk Criteria: A Configuration Guide

Sales professional reviewing a CRM opportunity pipeline dashboard with risk indicators on a widescreen monitor

A sales operations director at a mid-size distributor recently asked a reasonable question during a forecast review: why had the Sales Opportunity Agent flagged a deal with a signed letter of intent and an engaged economic buyer as high risk, while waving through a deal where the primary contact had gone silent for three weeks? The answer, once the architect behind the deployment dug into it, was that the agent’s risk model was still running on Microsoft’s default predictive scoring fields: stage velocity, close date slippage, historical win rate by deal size. None of those fields knew that this particular buyer’s procurement team always goes quiet right before signature, or that a champion’s sudden silence after a reorg announcement is the real warning sign in this account base. That gap between what a generic model measures and what an experienced seller actually watches for is precisely what Microsoft’s August 30, 2026 update to Sales Opportunity Agent risk criteria was built to close, and it changes what a technical rollout of this agent actually involves.

Until that update, configuring risk assessment in the agent meant choosing which existing Dynamics 365 fields fed the predictive opportunity scoring model and adjusting a handful of thresholds. Useful, but rigid. Now admins can add a custom risk criterion by describing it in plain language, and the agent layers that instruction on top of its default scoring rather than replacing it. For a solution architect or D365 CE technical consultant planning a rollout, that single change reshapes several downstream decisions: how selection criteria should be scoped, how many agent instances to run, and how much validation work happens before anyone trusts the output.

Sales professional reviewing a CRM opportunity pipeline dashboard with risk indicators on a widescreen monitor

What the Sales Opportunity Agent Risk Criteria Actually Do

The agent’s baseline risk assessment draws on the predictive opportunity scoring machine learning model already present in Dynamics 365 Sales. If that model isn’t configured in your environment, the agent triggers its setup automatically the first time it runs, which is worth knowing up front since it introduces a delay that has nothing to do with your own configuration work. On top of that baseline, the risk configuration section (found under Guidance in the agent’s settings page) now exposes an “Add a custom risk” option. Rather than mapping a field to a threshold, you write a description of the business condition you want flagged, and the agent interprets it against the data it has access to.

This is a meaningful departure from how most Dynamics 365 configuration has historically worked, where a business rule or classic workflow condition had to be expressed as an explicit field comparison. A natural-language risk criterion is closer to writing a prompt than writing a rule, which means two architects describing the same business concern could produce criteria that behave slightly differently depending on wording. That is not a flaw so much as a tradeoff: you gain the ability to capture tacit sales knowledge that was never going to get modeled as a formal Dataverse field, at the cost of the deterministic testability you’d expect from a traditional business rule.

Selection Criteria Come First, and They Are Easy to Get Wrong

Before any risk criterion runs, selection criteria decide which opportunities the agent even looks at. This is configured as a named segment (for example, “Enterprise renewals”) with filter conditions such as rating, estimated revenue, and status, plus an optional look-back period for including opportunities created before the agent was activated. Skip the look-back setting and the agent only considers opportunities created after activation, which catches teams off guard when historical pipeline doesn’t show up in the first few days.

The common mistake here is scoping selection criteria too broadly, on the theory that wider coverage means more value. In practice, loose criteria just mean the agent spends its processing cycles researching deals that were never going to close, competing for the same shared capacity pool as the opportunities you actually care about. A tighter starting point, something like status equals open, status reason equals in progress, and a revenue floor that reflects what “worth researching” means for your sales org, produces better signal and leaves headroom if you later add more segments.

It also helps to understand how the agent prioritizes work once multiple opportunities qualify, since this determines what gets attention first when capacity is constrained. The agent scores queued opportunities using several factors in order: estimated revenue, estimated close date, how recently the opportunity was researched, recent email activity, predictive win-rate score (lower scores get prioritized, since they need more attention), and whether a seller manually requested a refresh. That ordering matters operationally. A high-value deal with a distant close date will generally get processed before a smaller deal closing sooner, so if your sales leadership expects near-term renewals to surface first, you may need a separate agent instance scoped specifically to that segment rather than relying on the shared queue to sort it out.

Writing a Risk Criterion That Actually Earns Its Place

The temptation with natural-language configuration is to restate what the default model already covers, just in different words. That adds noise without adding insight. A custom risk criterion is worth configuring when it encodes something a seller already watches for informally but that no existing field captures well. A few examples that hold up in practice: flagging an opportunity when the primary contact’s job title has changed within the last 30 days, since a champion move is a known risk signal that stage and close-date fields won’t surface; flagging deals in a late stage with no email activity logged in the past two weeks, which tends to catch stalled deals before they slip a quarter; or flagging opportunities where a competitor’s name appears in recent email or meeting notes captured by the agent’s research, which surfaces competitive displacement risk earlier than a rep might think to log it manually.

Close-up of a laptop screen showing an abstract sales pipeline funnel visualization with risk-flag markers on deal nodes

Because these criteria are interpreted rather than evaluated against a strict rule, validate them the same way you’d validate any new logic before trusting it at scale. Use the Preview option in the selection criteria screen to check a representative sample, but treat that preview as directional rather than exhaustive, and cross-check with Advanced Find or a saved view before assuming the criterion behaves the way you intended. Configuration changes also don’t take effect until you explicitly apply them, and the agent only reprocesses on its configured refresh cadence of three, seven, or fourteen days, so budget a full cycle before concluding a criterion isn’t working.

Multiple Instances, One Shared Capacity Pool

Organizations can run up to ten active agent instances at once, each with its own profile, selection criteria, and knowledge sources, which is the mechanism for applying different risk logic to different parts of the business, say, enterprise deals versus transactional ones, without cramming every condition into a single configuration. The catch is that all instances draw from one shared Copilot Studio knowledge base and one shared capacity pool, so heavier use by one instance can slow research for another. If two instances’ selection criteria overlap, the instance with the earlier start time claims the opportunity, and that ownership sticks for the opportunity’s lifecycle. There’s no warning when criteria overlap, which means the discipline has to come from how you design segments up front rather than from anything the platform will catch for you.

The simplified admin configuration that reached general availability on June 30, 2026 helps here by offering guided setup with sensible defaults and a basic-versus-advanced configuration split, so a first instance can go live quickly and pick up custom risk criteria and finer-grained settings later. That’s a genuine improvement for getting started, but it doesn’t remove the need to plan selection criteria deliberately before adding a second or third instance, since the underlying shared-capacity constraints don’t change.

Getting Useful Signal Out of the Rollout

The August GA of custom risk criteria removes a real excuse that architects have had for a while: that the agent’s risk model didn’t understand the specific patterns of a given sales motion. It now can, provided someone takes the time to write criteria that reflect what sales leadership actually raises in forecast calls rather than restating stage and close date in prose. The work that remains is the same discipline any configuration project needs: scope selection criteria narrowly, verify with independent tools rather than trusting the preview alone, and treat a natural-language rule with the same scrutiny you’d give a workflow condition, because it is making decisions about what gets a seller’s attention.

Routeget Technologies has walked a handful of clients through standing up their first Sales Opportunity Agent instances this year, and the pattern that works best is starting with one tightly scoped segment, letting it run a few refresh cycles, and only then drafting custom risk criteria based on what actually surprised the sales team about the default output. That sequencing avoids the common failure mode of over-engineering risk logic before anyone has seen how the baseline model behaves against real pipeline.

#SalesOpportunityAgent #Dynamics365Sales #CRMConfiguration #OpportunityManagement #SalesAIAgents #CustomerEngagement

Business Central’s Outlook Integration Deadline Is October 1, 2026

IT professional reviewing an email and calendar dashboard, representing Business Central Outlook integration

An IT Director at a distribution company we work with found out about this deadline the way most people do: from a support ticket, not a Microsoft email. A sales rep’s Outlook add-in stopped letting her attach a quote from Business Central mid-thread, and the contact she’d synced from BC to Outlook six months ago had quietly vanished from the folder it used to sit in. Nothing had changed on her machine. What had changed was that her company’s Business Central environment was still two release waves behind, and Microsoft had already started tightening the plumbing underneath a feature nobody in IT had flagged as fragile.

That plumbing is Exchange Web Services, the aging protocol Outlook add-ins and contact sync in Business Central have leaned on for over a decade. Microsoft is retiring it, and the resulting Outlook integration deadline that Business Central’s own product team has set is considerably firmer than the platform-wide retirement schedule most IT leaders have heard about. If your organization runs Business Central and anyone in sales, purchasing, or accounting touches customer or vendor contacts through Outlook, this is worth twenty minutes of your attention before the end of the month.

IT professional reviewing an email and calendar dashboard, representing Business Central Outlook integration

What’s Behind the Outlook Integration Deadline

Exchange Web Services, usually shortened to EWS, is the API that has quietly connected Outlook to a long list of Microsoft and third-party applications since the mid-2000s. Microsoft first announced its deprecation back in 2018, but the timeline accelerated meaningfully after the Midnight Blizzard security incident in January 2024 pushed the company toward faster retirement of legacy authentication and API surfaces across Exchange Online. The result, as published by the Exchange engineering team, is a phased shutdown: EWS begins to be disabled globally starting in October 2026, with full disablement across all tenants by April 2027.

Business Central’s product group didn’t wait for that full window to close. Because the older Exchange-based contact synchronization and Outlook add-in deployment in Business Central depend directly on EWS calls, the team attached a much nearer deadline to its own 2026 release wave 1 features: organizations need to be on Business Central version 28.0 or later, and Microsoft has stated plainly that after October 1, 2026, Outlook add-in functionality and contact sync built on the older Exchange connection may stop working in earlier versions. That is a considerably tighter window than the broader EWS retirement calendar, and it is the one that actually matters if you’re planning around this.

What Breaks in Practice, Not in Theory

For a company still running a pre-28.0 version, the practical failure points are the ones your sales and finance teams touch daily rather than anything IT usually monitors. The Outlook add-in that lets a salesperson pull up a customer’s Business Central record, attach a quote, or check open invoice balances without leaving their inbox depends on that Exchange connection to authenticate and retrieve data. The legacy Exchange Sync. Setup page, which many mid-market Business Central customers configured years ago and then never touched again, uses EWS to keep a “Business Central” folder of synced contacts current in each user’s Outlook. Automatically tracking email correspondence against a customer record, a feature accounting and account management teams tend to rely on more than they realize until it’s gone, runs through the same plumbing.

None of this fails with a dramatic outage. It fails quietly: an add-in that used to load now times out, a contact that used to sync now sits stale, an email that used to log itself against a customer record now just sends. That’s a worse failure mode for a CIO to manage than a hard outage, because it doesn’t generate an incident ticket. It generates a slow trickle of user complaints that get diagnosed as one-off glitches for weeks before anyone connects them to a platform deprecation that IT technically knew about.

Abstract visualization of data synchronization flowing between two connected systems on a laptop screen

What Version 28 Actually Replaces It With

Business Central 2026 release wave 1, generally available since April 1, 2026 and auto-enabled for all users on that version, rebuilds this integration on Microsoft Graph instead of EWS. The most visible change is a new “Synchronize with Outlook” action added directly to the Contacts list, which copies selected contacts from Business Central into Microsoft 365, making them usable in both Outlook and Teams. Unlike the old Exchange Sync. Setup configuration, which required a separate admin setup flow and validated an Exchange connection before anything would sync, this action sits where sales and account teams already work, and it supports syncing in either direction if an organization wants contacts created in Outlook to flow back into Business Central.

The other change worth flagging to your security and IT operations teams directly is that Outlook add-in installation now requires a one-time additional setup step to verify the account, a deliberate friction point Microsoft added for account protection reasons rather than a bug. If your organization uses centralized deployment to push the Business Central add-in to users automatically rather than relying on individual installs, that deployment process still works, but the added verification step means it is worth testing the rollout against a pilot group rather than assuming a push that worked in 2025 will behave identically in 2026.

Who Is Actually at Risk

If your Business Central environment is a standard SaaS deployment on Microsoft’s evergreen update cadence, there’s a reasonable chance you’re already on version 28.0 or close to it, since Microsoft pushes two release waves a year to every SaaS tenant on a schedule customers don’t fully control. The organizations that should be checking their version today rather than assuming they’re covered fall into a narrower but not small group: companies running Business Central on-premises, where upgrades are a deliberate IT project rather than an automatic platform event; companies that migrated from Dynamics GP, NAV, or SL in the last two years and may still be running an early post-migration version they haven’t touched since go-live; and any organization that has deliberately delayed a release wave update because of a customization or third-party integration compatibility concern, which is common enough in manufacturing and distribution environments with heavily extended BC implementations.

Checking your version takes a few minutes: in Business Central, the Help and Support page shows the current version and build number directly, and any IT Director who can’t answer “what release wave are we on” from memory should treat that itself as a minor governance gap worth closing regardless of this specific deadline.

What to Do Before October 1

The organizations that will sail through this deadline without incident are the ones treating it as a two-part check rather than a single upgrade task. The first part is confirming the Business Central version itself, since anything at 28.0 or later already has the Graph-based integration and doesn’t need to do anything further beyond being aware the old Exchange Sync. Setup pages are being phased out and shouldn’t be reconfigured going forward. The second part, and the one that gets missed, is validating that Outlook add-in deployment and any automated email-tracking workflows actually work end to end after an upgrade, not just that the version number changed. An upgrade that technically completes but leaves the add-in’s new security verification step unaddressed for most users produces the same quiet failure pattern as not upgrading at all, just with a shorter fuse. For any organization using EWS-dependent integrations beyond Business Central itself, Microsoft’s own EWS Usage Reports in the Microsoft 365 admin center are worth a look this month, since Business Central is rarely the only application in a tenant still calling that API.

None of this requires a large project. It requires someone in IT confirming a version number, someone in sales or finance confirming the add-in still authenticates cleanly, and roughly three weeks of runway that is shrinking by the day. Routeget Technologies has walked several clients through exactly this check in the past month, and in every case the fix was smaller than the anxiety the deadline initially produced, provided someone looked at it before October 1 rather than after.

#BusinessCentral #OutlookIntegration #ExchangeWebServices #ERPGovernance #Microsoft365Integration #DynamicsMigration

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

Standard vs Custom Dataverse Tables: The Schema Decision That Compounds

Solution architect reviewing an entity-relationship diagram of Dataverse tables on a wall-mounted monitor in a modern office

A solution architect reviewing a Dataverse environment for a mid-market industrial services client recently found three separate custom tables, each carrying a different prefix from three different implementation phases, all describing the same thing: a physical site where equipment lived. One had been built by an internal power user modeling “Locations.” Another arrived bundled with an asset management add-on that already shipped a standard table for exactly this purpose. A third was created eighteen months later by a consulting partner who never checked whether either of the first two existed. None of the three synced with each other. Field technicians updated one, finance reported from another, and a Copilot Studio agent built the following year queried a fourth table that didn’t even have the data anyone actually needed.

This is not an unusual story. It is close to the default outcome when the standard vs custom Dataverse tables decision gets made under sprint pressure by whoever is in the room that week, without anyone asking a simple question first: does a standard table already do this?

Solution architect reviewing an entity-relationship diagram of Dataverse tables on a wall-mounted monitor in a modern office

Why the standard vs custom Dataverse tables decision is easy to get wrong

Dataverse ships with hundreds of standard tables (Account, Contact, and Case are the obvious ones, but plenty of others arrive silently through installed solutions like Asset Management, Project Operations, or Customer Service) built on the Common Data Model, Microsoft’s shared schema for representing common business concepts consistently across apps. These tables carry no prefix. A custom table, by contrast, always carries one, whether that’s a publisher prefix like cra_ or a legacy new_. That naming convention is the fastest way to tell which category a table belongs to, but it only helps if someone actually looks.

The reason teams skip that check is rarely laziness. It is usually that building a new custom table feels faster and safer than researching whether a standard one already covers the need, especially early in a project when the backlog is long and the standard table’s full column list and relationship graph aren’t obvious from a quick glance at the maker portal. The problem is that this shortcut doesn’t cost you anything visible in week one. It costs you eighteen months later, when a Fabric Link migration, a cross-application integration between Finance and Operations and Customer Engagement, or a Copilot Studio agent expects the canonical CDM entity and instead finds three partial, disconnected substitutes.

What actually distinguishes standard, custom, and virtual tables

The decision isn’t really binary. There are three categories worth holding in mind, and each answers a different question about who owns the data’s lifecycle.

Standard tables are the right choice when Dataverse itself is the authoritative source for that data and the concept maps to something Microsoft has already modeled: a contact, an account, a case, a work order. Even when a standard table doesn’t fit perfectly out of the box, most standard tables are customizable, meaning you can add columns, choices, and relationships to extend them without forking the concept into a parallel structure. Extending a standard table keeps every existing app, flow, security role, and future Copilot agent that already understands that entity working correctly, because they’re still querying the same canonical table, just with a few more fields on it.

Custom tables earn their place when the data genuinely doesn’t correspond to anything in the Common Data Model and is specific to how your organization actually operates: an internal certification tracking table, a custom approval matrix, something with no reasonable standard analog. The mistake isn’t creating custom tables. It’s creating one before checking whether the concept already has a home.

Virtual tables solve a different problem entirely: they matter when an external system, not Dataverse, remains the true owner of a record’s lifecycle. A virtual table stores only metadata in Dataverse and queries the external source (an ERP system, a warehouse management platform, a legacy line-of-business database) live, through a data provider. This matters more than it sounds like it should, because the alternative, replicating that external data into a standard or custom Dataverse table on a schedule, introduces a staleness window that can turn into a real operational failure. If a warehouse system shows zero units on hand but the last Dataverse sync ran six hours ago and still shows ten, a sales rep can quote stock that doesn’t exist, and the order gets canceled after the customer has already been told it’s on the way. Virtual tables avoid that gap by not caching the data at all, at the cost of depending entirely on the external system’s availability and performance for every query.

Close-up of a laptop screen showing an abstract database table relationship diagram on a desk

The decision doesn’t stop at the table level

Getting the table category right is only the first layer of the structure question. Once you’ve decided a standard table is the right home for a concept, the choice columns and relationships you add to extend it are where a lot of the same discipline quietly gets abandoned. A choice column added to the standard Case table to capture an industry-specific status, for instance, is a reasonable extension. A parallel custom table built solely to hold a lookup list of those same statuses, connected back to Case through a one-to-many relationship that duplicates logic the choice column could have handled directly, is the same mistake as the duplicate-table problem, just one level down. Relationships matter here too: a standard table’s existing relationships to Account, Contact, or Activity records represent years of Microsoft’s own modeling work and every prebuilt view, form, and security role built around them. Recreating an equivalent relationship structure on a new custom table means none of that inherited tooling applies, and every new integration has to be taught the relationship from scratch. The pattern to watch for is simple: if you’re building a new table or relationship whose only real justification is that it mirrors something a standard table’s fields or connections already do, that’s usually a sign to extend the standard structure instead of building a parallel one next to it.

Where this decision shows up again at the platform level

Microsoft’s own tooling has started reflecting how much this decision matters beyond a single app. Guided table selection for Dataverse-to-Fabric sync, which reached general availability in March 2026, now lets administrators choose which tables get synced to Microsoft Fabric before any data movement happens, rather than syncing everything by default and cleaning up storage and compute costs after the fact. That capability is far more useful, and far cheaper to operate, when the tables being selected are standard, CDM-aligned entities that Fabric, Copilot, and cross-application processes already expect, instead of a scattered set of custom tables that each need to be individually understood, mapped, and maintained by whoever inherits the environment next.

The same logic applies to Copilot Studio agents built against Dataverse. An agent configured to reason over the standard Account or Case table benefits from every piece of existing metadata, relationship, and security context Microsoft has already built around that entity. An agent pointed at a custom table invented to avoid learning the standard schema starts from nothing, and every future integration against that data has to rediscover the same ground.

A practical check before the next table gets created

Before greenlighting a new custom table, it’s worth spending twenty minutes on three checks that would have caught the industrial services example above. First, search the environment for a standard table whose name or description plausibly matches the concept, since standard tables installed by add-on solutions often don’t surface in a maker’s mental model of “what’s already in this environment” the way tables they built themselves do. Second, if a standard table exists but seems incomplete, check whether it’s marked customizable before assuming it needs to be replaced rather than extended, since most standard tables accept new columns, choices, and relationships without any loss of the functionality that came with them. Third, before replicating any externally-owned data into Dataverse on a schedule, ask explicitly whether the business can tolerate a sync delay, because if the answer is no, a virtual table is very likely the more honest architectural choice, even though it takes more setup effort than a straightforward custom table import.

None of this is exciting work, and it rarely shows up as a line item any client asks for by name. But schema decisions are the one architectural choice in a Dataverse implementation that nobody revisits for years, which is exactly why they deserve more scrutiny at the start than they usually get. Routeget Technologies typically includes a standard-table gap analysis as one of the first steps in any new Dataverse engagement, precisely because the cost of fixing a schema mistake grows every quarter it goes unnoticed, while the cost of catching it early is measured in a single afternoon of research.

#DataverseArchitecture #CommonDataModel #PowerPlatformGovernance #DataverseSchema #FabricLink #EnterpriseDataStrategy