Power BI Semantic Model Refresh Just Got Granular. Your Dynamics 365 Reports Still Refresh Everything.

A solution architect reviews a data refresh and capacity monitoring dashboard on a large screen at night

A Fabric capacity dashboard turning red at two in the morning is one of the more specific kinds of dread in Dynamics 365 reporting work. Somewhere in the tenant, a scheduled job kicked off a full refresh of a forty-table semantic model built over Dataverse-linked Finance and Operations data, and now every other overnight pipeline is queued behind it. The general ledger fact table alone might carry a decade of posted transactions. None of that history changed since yesterday. It gets reloaded anyway, because until recently, “refresh” in Power BI meant one thing: everything, from scratch, every time.

That default is finally negotiable. Power BI’s August 2026 update made granular semantic model refresh controls generally available in both Desktop and the service, giving report owners a real choice between refreshing schema, refreshing data, or refreshing both, down to the level of an individual table. For anyone maintaining Power BI models over Dynamics 365 F&O, Business Central, or Dataverse data more broadly, this is the kind of change that should prompt an actual architecture review rather than a shrug and a changelog skim.

What changed, specifically

The expanded Refresh control in Power BI Desktop and the service now exposes three distinct operations instead of one. Refresh Schema and Data is the familiar default: Power BI checks the source for structural changes, applies them, and then reloads data. Sync Schema Only updates the model’s structure, picking up new or renamed columns and data type changes, without pulling fresh rows. Refresh Data Only does the opposite: it reloads current values while deliberately ignoring any structural drift at the source, which matters more than it sounds like it should when a source system adds a column you have no interest in modeling yet.

Critically, this granularity now applies at the table level through the UI itself, not just through a REST call. Select a table in the Data pane, and you can choose to refresh its schema, its data, or both, independently of what happens to the rest of the model. Under the hood, this builds on the Enhanced Refresh API’s objects parameter, which has supported table- and partition-level targeting in JSON refresh requests for several years. What is new is that the capability is no longer something you had to script or automate through Power Automate to get; it is a first-class option in the interface most report authors actually use.

The timing lines up with Direct Lake’s move to general availability for OneLake semantic models in March 2026. Direct Lake models query OneLake data at query time instead of importing it into a separate in-memory copy, which changes what “refresh” even needs to accomplish. A schema-only sync is explicitly called out as the more sensible operation for many Direct Lake scenarios, since the underlying data is already current in OneLake and what actually needs updating is the model’s awareness of structural changes upstream.

Why Dynamics 365 semantic model refresh costs add up fast

Generic BI advice treats all semantic models as roughly interchangeable, but Dynamics 365 F&O and Business Central models have a particular shape that makes blanket full refreshes disproportionately expensive. A handful of tables, typically the ones behind AP aging, open sales orders, or current inventory positions, change constantly and need frequent, current data. Most of the rest of the model, historical GL transactions, closed projects, prior fiscal years, is functionally read-only from one day to the next. When Fabric Link or the older entity-store approach lands both categories in the same semantic model and a nightly job refreshes the whole thing on one schedule, the model pays the full cost of reprocessing static history every single time it wants fresh numbers for the tables that actually moved.

That cost shows up in two places that matter to whoever owns the Fabric capacity bill. Wall-clock refresh duration extends as historical fact tables grow, which is a slow-motion problem that eventually collides with the maximum refresh duration ceilings on shared and Premium capacity. And CU consumption on Fabric capacity is metered by the compute the refresh operation actually performs, so reprocessing unchanged partitions burns capacity that has no analytical payoff. Neither problem is solved by adding capacity; both are solved by refreshing less.

Applying granular refresh to a Dynamics 365 semantic model

The practical starting point is an honest table-by-table audit of your existing model, sorted by two questions: does this table’s data actually change day to day, and does its schema drift when Microsoft ships a Finance and Operations or Business Central update. Tables like open transactions, current inventory on-hand, and active project status are obvious candidates for a Refresh Data Only cadence that runs frequently, maybe hourly if the business case justifies it, without touching schema at all. Large historical fact tables, closed fiscal periods, and reference dimensions that rarely change structure are candidates for a much less frequent Refresh Schema and Data pass, perhaps weekly, with the understanding that if Microsoft renames a field or adds a column mid-week, you will not see it in the model until the next scheduled schema sync.

Abstract illustration of a few illuminated data table blocks refreshing among many dimmed, unchanged ones

Where this pairs particularly well with existing Power BI capability is incremental refresh policies on the largest transaction tables. Incremental refresh already partitions a table by date so that only the current period’s partition gets reprocessed on a routine basis; layering table-level refresh selection on top means you can decide, table by table, whether even that partitioned refresh needs to run tonight or can wait until the weekend. For a semantic model spanning several Dynamics 365 legal entities, this combination is usually the difference between a refresh job measured in tens of minutes and one measured in hours.

Implementing this through the Enhanced Refresh REST API rather than clicking through the UI is worth the extra setup for any model refreshed on a schedule, because it lets you express the table list as configuration rather than tribal knowledge sitting in someone’s memory of which tables to click. A request that targets specific tables through the objects array, with applyRefreshPolicy set appropriately for whether you want the incremental refresh window respected, is straightforward to build and far easier to audit six months later than a manual process. Teams running Power Automate flows or Azure Data Factory pipelines to orchestrate refreshes should treat this as the moment to replace a single “refresh the whole dataset” call with a small set of targeted requests, each on its own cadence.

Where this still needs judgment, not just configuration

Schema-only sync deserves particular caution in Dynamics 365 contexts because Microsoft’s release cadence for F&O and Business Central genuinely does add and rename fields with some regularity, and a model that never runs a full schema sync will eventually diverge from its source in ways that surface as confusing blank columns or broken relationships rather than clean errors. A reasonable middle ground is to schedule schema syncs on their own cadence, independent of data refreshes, rather than skipping them indefinitely because a table’s data refresh doesn’t need one.

It is also worth being explicit with report consumers and downstream teams about which tables now run on which schedule, since the old assumption that “refreshed this morning” meant the entire model was current no longer holds once refresh granularity is in play. A short data dictionary note next to each table, or a dedicated tab in the workspace documentation, prevents the kind of confusion where someone builds a decision on a historical table that was deliberately left out of last night’s run.

The architecture conversation this actually forces

The real value of granular refresh isn’t the UI convenience, it’s that it forces a semantic model design conversation that most Dynamics 365 reporting teams have been avoiding: which tables in this model are operational and which are archival, and should they even live in the same refresh schedule, or the same model, at all. Teams that have this conversation now, while the tooling to act on the answer just became native to the product, will end up with leaner Fabric capacity bills and faster refresh windows than teams that keep treating every semantic model as a single monolithic refresh unit. At Routeget, this is usually the point in a Fabric or Power BI engagement where we walk a client’s existing model inventory table by table rather than accepting the assumption that a full nightly refresh is simply the cost of doing business with ERP-scale data.

#PowerBIRefresh #SemanticModels #DirectLake #FabricCapacity #DynamicsFinanceOps #BusinessCentral

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