Enterprise BI Operations

In an illustrative scenario, a company buys a BI tool, and for a year everything works. Then someone counts: four hundred dashboards, nine tables that all claim to hold revenue, a Monday morning when every report is slow, and one analyst who left in March and owned eleven of the things executives read. Nobody did anything wrong. The tool made the first dashboard easy and did nothing to make the four hundredth manageable.

Power BI and Tableau make it easy to create reports. Keeping them usable as authors, content, and readership grow requires decisions about refresh, capacity, access, and ownership. The product limits below follow the linked documentation; check them before sizing a deployment.

Where the data sits decides everything downstream

Every BI tool offers the same fundamental choice: copy the data into the tool’s own engine, or query the source each time. Power BI calls these Import and DirectQuery; Tableau calls them extracts and live connections. The names differ and the trade does not.

	Copy it in (Import / extract)	Query the source (DirectQuery / live)
Query speed	Fast — an engine built for it. Tableau documents that extract-based views show “better performance compared to views connected directly to the original data”	As fast as the source under concurrent load, which is usually the real constraint
Freshness	Reflects the source data included in the last refresh; source delays can make it older still	Reflects what the source returned for the last query, subject to caches and upstream delays
Load on the source	Concentrated in the refresh window	Spread across the interactions that miss the caches — including the ones nobody planned for
What it costs you	Memory and refresh capacity in the BI platform	A source that must absorb interactive query patterns it was not sized for
Offline use	Possible — extracts “allow for offline access to data”	No

DirectQuery does not continuously update an open page. Microsoft documents that navigation, filters, manual refresh, or configured automatic refresh can trigger new queries, while visual, tile, and result caches can retain earlier results. DirectQuery dashboard tiles use a separate refresh schedule, hourly by default and configurable down to fifteen minutes. Different visuals can query at different times, so refreshing a page does not by itself produce a consistent snapshot.

For a wall display, configure and measure page refresh rather than assuming a live connection keeps the screen current. Power BI Automatic Page Refresh supports short intervals, including one second under supported connection, capacity, and administrator settings. If queries take longer, actual updates are slower. This can support near-real-time reporting, but a configured interval is not a strict end-to-end freshness guarantee. Show the query or model refresh time separately from the source event cutoff and coverage; fetching an old source again does not make its data current.

Two further consequences are worth stating before the first model is built. On a live connection, a filter click that has to be answered from the source puts load on an operational or warehouse system — not every click does, since the service “caches some results” and an “exact repeat” query can be served from cache, and an aggregation table can absorb a common query without touching the source. What this means for planning is that capacity comes from the queries that actually reach the source, so the number to measure is the cache miss rate and the source-side query volume rather than the number of interactions. And a copy is a copy: it is a second place the numbers live, with its own refresh state, and the reporting cutoff it implies has to be stated on the report rather than assumed by the reader.

Where the copy exists, incremental refresh is what keeps the cost bounded. Both products offer it, both scope it to a window you choose, and the window is where late corrections are won or lost.

Tableau supports incremental extracts that append new rows, and version 2024.2 added a minimum date range to refresh previously extracted data. Re-extracting that subrange can capture changes within it. The Refresh Extracts documentation also identifies timestamp precision differences as a possible source of duplicates and requires a full extract refresh after structural changes such as adding a column. Choose the append or subrange settings to match how the source changes.

Power BI partitions imported data by date. Its policy separates a rolling refresh period from historical periods that are no longer routinely refreshed. Reprocessing yesterday’s partition can pick up a correction to yesterday’s row; a correction in an older, untouched partition needs a separate refresh. With Detect data changes, Power BI compares the selected audit column’s maximum value for each period and can skip periods whose signal has not changed. This narrows the work; it does not widen the refresh window.

Change detection needs a signal for every relevant change. A hard deletion can leave a period’s maximum audit timestamp unchanged, so the period is skipped and the deleted row remains in the model. Microsoft documents soft deletion with an updated change timestamp as a detectable pattern; the resulting query must exclude deleted rows. Changes outside the refresh window still need an explicit reprocessing or reconciliation path. Likewise, Tableau’s append-only configuration does not repair earlier rows that it never rereads. Size the window and the recovery process together.

The decision this forces is usually left unmade: how far back a correction is allowed to arrive. That answer sets the window, or the full-refresh schedule, and without it late corrections are absorbed silently — the report is simply wrong in a way no refresh log shows.

Size for refresh and interactive load

A full Import-model refresh can retain the existing model for readers while processing its replacement. That can require roughly two model copies plus processing memory, with concurrent queries adding their own temporary memory. Incremental or selected-partition refresh reduces the data reprocessed and can reduce this requirement. Measure the processing scope and query load instead of applying a fixed multiplier to every refresh.

For example, retaining a 20 GB model while rebuilding the full replacement can exceed 40 GB once processing and queries are included. This is a full-refresh planning example, not a minimum for every incremental refresh. The documented maximum model memory is 25 GB on F64 and 100 GB on F256, with room needed for operations as well. Check model and query limits separately, and test the intended refresh alongside peak reader concurrency; fitting at rest does not establish that the workload fits.

Microsoft describes scheduled refresh as best effort, subject to each SKU’s model refresh parallelism limit. When simultaneous demand exceeds that limit, some models must wait; twenty scheduled models do not necessarily exceed every SKU’s limit. Stagger work by dependency and priority, and measure completion against the report’s freshness target.

Shared capacity means shared consequences

Enterprise BI platforms sell compute as a pool. Power BI’s documentation defines it plainly: a capacity is “a distinct pool of resources,” and “the size of the capacity determines the amount of computation power available.” Everything assigned to that pool competes for it, which makes BI capacity a design decision rather than a purchase.

For Fabric capacity, CPU or CU utilization above 100% does not by itself mean requests are throttled. Fabric smooths consumption over time and uses accumulated consumption of future capacity to determine delays and then rejection of new operations. A sudden workload increase can exhaust that protection without weeks of warning. Use the Capacity Metrics app’s throttling and overages views to distinguish this from a slow query or source bottleneck. Separate product limits also apply, including the documented 225-second Power BI visual rendering timeout.

Power BI Premium P-SKU Autoscale can add v-cores at 30-second intervals up to the configured limit when interactive throttling begins. Each added core stays active for at least 24 hours and is billed to an Azure subscription. This P-SKU mechanism is not available for Fabric F SKUs; for those, plan resizing, workload movement, or load reduction. Record the SKU family and expansion limit in the capacity plan, and monitor the cost of any automatic expansion.

A shared capacity can reduce idle resources, but it is not always the cheapest way to meet a given response-time target. Compare total resources, SKU and licensing constraints, operating hours, and peak overlap under the same SLO. Separate capacities reduce interference within the BI compute pools; they can still contend on a shared source, gateway, or network. Choose the isolation boundary from the workload commitment and test those common dependencies.

Correlate pool utilization and throttling with report latency, errors, source timings, and refresh completion. A slow report can be the victim of shared load or the source of it, and pool averages alone cannot distinguish those cases. Attribute consumption to teams so that investigations and cost decisions reach the people who can change the workload.

Row-level security is where a small mistake becomes a large one

Most enterprise reporting needs the same report to show different rows to different readers — a regional manager sees their region. Row-level security is the mechanism, described by Tableau as the ability to “filter data based on the user that is requesting it.” The mechanism is not the hard part; where it is enforced is.

Where the rule lives	How it works	What can go wrong
In the workbook, mapping users to values by hand	An author lists who sees what	Goes stale the day someone changes role, and does not scale past a handful of names
In a calculated field	The filter derives the viewer’s entitlement automatically	Still per-workbook. Tableau notes that with these approaches “permissions must be secured to prevent users from seeing unfiltered data” — the rule is only as good as the permissions around it
In a central data policy	Enforced once, in a virtual connection, for everything that uses it	Requires the connection to be the only path to the data. Tableau’s point is that it avoids “the same risk of exposing information if an author neglects to properly secure permissions”
In the database	The source refuses to return rows the user may not see	Requires a trustworthy user or tenant context through a supported connector: delegated identity or a trusted application session context. The database and integration determine the available policies.

Power BI semantic-model RLS applies to workspace Viewers, including Viewers with Build permission and those using Analyze in Excel. Workspace Admins, Members, and Contributors can edit the model and are not restricted by its RLS. Giving every reader Contributor access therefore defeats that model-level restriction. Review effective permissions as well as role definitions.

RLS filters rows; it does not hide sensitive columns within permitted rows. Use object-level security where column access must also be restricted. For database enforcement, SQL Server demonstrates a trusted middle-tier application sharing one database account and setting the user ID in SESSION_CONTEXT. This requires a supported integration that controls the context, prevents users from impersonating another tenant, and handles connection reuse correctly. It is not a feature every BI connector provides.

The pattern across the table above is that per-workbook enforcement makes every author a security boundary. One person duplicating a workbook and forgetting to reapply the filter exposes everything — and that failure is silent, because the report renders perfectly. Central enforcement converts a repeated human step into a single configured one, which is the entire argument for it.

Whatever the mechanism, two checks belong in the routine. Enumerate every path to the data, not just the certified report: an export, a direct connection from a notebook, or a second workbook built on the same source can bypass a rule enforced only in the first one. And test as a member of each role rather than as an administrator, since least privilege is only real if someone has verified what a low-privilege account actually sees.

Self-service produces content faster than anyone retires it

The point of self-service is that people do not wait for a queue, and it works: the number of reports grows. What no tool does by default is remove any of them. Five years in, a platform holds hundreds of dashboards where a few dozen are used, several contradict each other, and the ones executives quote are not always the maintained ones.

The mechanism that helps is not a restriction on authoring. It is making the difference between a maintained report and an exploration visible, which is what content certification is for: a maintained set of endorsed content with a named owner, a stated definition, and a refresh commitment, and everything else clearly marked as unendorsed. Three rules make it hold.

• Certification means someone signed up for an obligation. An owner, the metric definitions it uses, a freshness target stated as an objective, and a review date. A badge without those is decoration, and readers learn to ignore it.
• Personal work stays separate from shared space. Separation helps readers identify work in progress, but shared links or exports can lose that context. Label endorsement status, control sharing paths, and check ownership before promoting content.
• Retirement is a scheduled activity. Usage logs identify retirement candidates within their recorded period and access paths. Before removal, check seasonal or annual use, downstream dependencies, distribution routes, ownership, and retention needs. Then notify affected users and follow an archive-and-removal policy; silence alone is not proof that content is unnecessary.

Certification also depends on something upstream of the BI tool. If the certified report and an analyst’s own query disagree because the metric is defined in two places, no badge resolves it — that is the definition layer’s job, and a BI platform can only surface the answer it is given. Where reports are consumed by other teams as though they were products, the promise about definitions and freshness belongs in a data contract rather than in a shared understanding.

Ownership, and how to tell whether any of this works

Most BI trouble traces to an unowned artifact. The platform itself needs an operator — capacity, upgrades, access model — and each piece of shared content needs someone accountable for what it says. Those are different roles, and conflating them is how a platform team ends up answering questions about a definition it did not write. The owner, steward, and custodian distinction transfers directly, and the same governance question applies: who decides, and where is it written down.

Treating shared reports as a data product puts that on a familiar footing — a named owner, a stated audience, a documented definition, a support expectation — and it also makes the number of products a deliberate decision rather than a byproduct of how many people had an idea.

Four measures say whether the platform is healthy, and none of them is the report count.

• Share of viewing on certified content. Track adoption with a stated period, audience, and denominator. A rise can reflect default links or fewer views of other content; a stable high share need not mean readers ignore certification. Use feedback and reported issues to assess trust.
• Ownership coverage of shared content — the BI equivalent of catalog coverage, a way to find accountability gaps rather than a predictor of the next incident.
• Refresh reliability against the stated freshness target, not average refresh duration.
• Capacity headroom during peak hours. Use longer-term trends for sizing and short-term alerts on throttling, latency, errors, and refresh SLOs for operational response. Bursts and new workloads can cause trouble before a monthly review.

Start with a bounded set of important reports, such as five used by executives. Give each a named owner, confirm its definitions and freshness target, and certify it only after those commitments are supported. The effort depends on the gaps discovered; the useful outcome is a maintained answer and a clear route for questions.

References

• Microsoft Learn, What is Power BI Premium?
• Microsoft Learn, Using Autoscale with Power BI Premium
• Tableau Help, Extract Your Data
• Tableau Help, Refresh Extracts
• Tableau Help, Overview of Row-Level Security Options in Tableau
• Microsoft Learn, Incremental refresh and real-time data for Power BI semantic models
• Microsoft Learn, DirectQuery in Power BI
• Microsoft Learn, Row-level security (RLS) with Power BI
• Understand capacity throttling and smoothing
• Configure incremental refresh and real-time data
• Automatic page refresh in Power BI
• Row-Level Security — SQL Server