Power BI Reports: Building, Sharing, and Refreshing

The most expensive hour in most analytics teams is the one spent rebuilding a report that already exists, because nobody trusts the version that shipped last quarter. The chart was fine. What broke trust was everything around it: a gateway that stopped refreshing in March, a filter that silently excluded a new sales region, a row level security role that let a regional manager see the whole company, and a distribution list of forty people of whom four have opened it since launch. Power BI reports fail in the plumbing far more often than they fail on the canvas, and this guide is organised around that fact.

What follows is the lifecycle: the model underneath, the report on top of it, the sharing decisions that determine who can see it, the refresh architecture that decides whether the numbers are current, and where Power BI Report Server still earns its licence.

Power BI reports vs dashboards: the distinction that keeps causing arguments

Almost every confused Power BI conversation traces back to the word "dashboard" covering three different objects. Microsoft's own vocabulary is precise, and using it loosely costs real time in planning meetings.

A report is a multi page artifact built in Power BI Desktop (or the browser) on one dataset, now called a semantic model. It is interactive: cross filtering, slicers, drillthrough, bookmarks.

A dashboard in the Power BI service is a single page canvas of tiles pinned from several different reports and models. It cannot be built in Desktop, it does not support cross filtering between tiles, and it exists mostly as a landing screen. Many teams now skip dashboards and publish an app with a well designed report page as the front door.

A paginated report (the SSRS lineage, built in Power BI Report Builder) is pixel precise and made for printing, which makes it right for a 200 page invoice run or a regulator ready PDF, and awkward for everything else.

One line to remember: build reports, distribute apps, and reach for paginated reports when the deliverable is a document rather than a screen. Which artifact fits which job is covered further in Data Visualization Tools: How to Choose the Right One.

Start with the model, because the report inherits every mistake

The strongest predictor of whether Power BI reporting goes well is the semantic model. A report is a thin layer of presentation over it, and no amount of visual polish rescues a bad one.

Shape the model as a star schema. One fact table per business process, surrounded by conformed dimensions. This is the shape VertiPaq and DAX filter propagation are designed for. Flat wide tables pulled from a spreadsheet work for a while, then produce ambiguous relationships, broken totals and slicers that filter the wrong things.

Build a proper date table and mark it as one. Almost every DAX time intelligence function assumes a contiguous date dimension. Skipping this is why "same period last year" quietly returns blanks.

Push transformations upstream. Anything doable in the source is cheaper than Power Query, which is cheaper than DAX calculated columns. Prefer measures for aggregation: they evaluate in filter context and cost nothing at refresh, while every calculated column sits in memory and rebuilds every cycle.

Name things the way the business names them. If finance says "net revenue," the measure is Net Revenue, not sum_rev_net_v2. Hide technical keys from report view. The field list is a user interface.

Decide storage mode deliberately. Import is fastest to query and requires refresh. DirectQuery keeps data live at the cost of performance and a long list of DAX limitations. Composite models mix the two, and Direct Lake on Fabric gives Import-like speed over OneLake without a copy. Default to Import, and move off it only for data volume or a freshness requirement measured in minutes.

If you end up owning all of this, the role has a name and a wide job description: What a Business Intelligence Analyst Actually Does describes the work fairly, most of which is not chart building.

Building Power BI reports people actually read

With a clean model, report building becomes a design problem rather than an engineering one.

One page, one question. The best Power BI reports answer a specific question on the first page and let people drill for detail. Eleven visuals answering eleven unrelated questions gets read as wallpaper.

Lead with the number, then the trend, then the breakdown. Card, line, bar. That order matches how people consume performance data and survives being viewed on a phone.

Use bookmarks and drillthrough instead of adding pages. A detail page reached by right clicking a bar is contextual. A detail page in the tab strip is a page nobody clicks.

Set interactions on purpose. By default, clicking a visual cross filters the others. Sometimes that is right, sometimes it confuses people who did not realise they left a filter applied.

Run the performance analyzer before you ship. A slow report is almost always one bad measure or one visual returning too many rows, and the analyzer finds it in minutes.

Set formatting, sort orders and accessibility defaults once, in the model. Alt text, sensible tab order, adequate contrast, no reliance on colour alone. Do it in the report and the next report starts from zero.

None of this is Power BI specific. The gallery in Tableau Dashboard Examples and What They Are Good For is a useful cross reference, because layout patterns translate even though the tooling does not. One platform caveat catches teams every year: Power BI Desktop is a Windows application. If part of your team is on macOS, use the ranked options in Power BI on a MacBook: Every Working Option, Ranked rather than discovering the constraint mid project.

Power BI report sharing: workspaces, apps, and links compared

Publishing is trivial. Choosing the distribution mechanism is where governance is won or lost, and the paths are not interchangeable.

Three rules follow. Apps are the default for any audience above a handful of people, because app audiences show different content to different groups from one workspace, the requirement teams reinvent badly with extra workspaces. Publish to web should be disabled at tenant level unless you have an explicit reason, since it creates an anonymous public URL. Exports are a leak you can manage but not close: a PDF in an inbox is permanent, unrefreshed and unpermissioned, so a subscription with a fresh render beats manual exporting.

If Power BI report sharing licences are driving your evaluation, the per seat maths deserves scrutiny. Tableau Alternatives Pricing Compared for Larger Teams walks the same trade in the other direction, and the pattern it identifies, per seat cost plus capacity plus paid extras for the parts you assumed were included, applies to Power BI just as cleanly.

Refreshing Power BI reports: gateways, schedules, and the failure points

This is where trust is earned or lost. A beautifully built report showing data from eleven days ago is worse than no report, because someone will decide on it.

Scheduled refresh applies to Import mode models: up to eight refreshes a day on Pro, up to 48 on Premium or Fabric capacity, plus the XMLA endpoint and enhanced refresh via the API. If you need hourly on a Pro workspace, you cannot have it.

Gateways are the most common single point of failure in the stack. Any cloud refresh touching an on premises source goes through the on premises data gateway, and the failure modes are boringly consistent:

• The gateway lives on one analyst's laptop, which sleeps or gets reimaged.
• The service account password expires and nobody owns the credential.
• The gateway is not clustered, so one VM reboot stops every refresh in the tenant.
• The version falls out of support, because updates are manual.
• Stored credentials are updated on one cluster member but not the others.

The fixes are unglamorous and they work: a dedicated server, a cluster of at least two members, a centrally managed service account, update notifications to the owning team, and monitoring of refresh outcomes instead of waiting for complaints. The per model refresh history dialog does not scale past a handful of items; on capacity, the Fabric Capacity Metrics app gives a real view. At minimum, failure notifications should land in a shared channel, not one person's inbox.

Incremental refresh is worth setting up whenever a fact table is large or the source is slow. Partition by date, refresh the recent window, archive the rest. It turns a 40 minute nightly job into a two minute one.

Ownership matters more than it looks. If the listed model owner is a departed employee, refresh stops and the error message is unhelpful. Takeover is a one click fix nobody performs, because nobody is watching.

Row level security gaps, and the audit nobody schedules

Row level security is DAX filter expressions on tables, assigned to roles, with users or groups mapped to those roles in the service. It works well, and it fails quietly, which is worse than failing loudly. The recurring gaps:

Roles defined but never assigned. The model has a Regional Manager role with a correct filter and zero members in the service. Everyone with workspace access sees everything.

Workspace membership overriding RLS. Members and admins bypass row level security on models in their workspace. A user who must be filtered has to be a Viewer, or better, consume via an app.

Filters covering only the fact table. If a role filters Sales but not Customer, slicers still reveal the full customer list even when the numbers are filtered. Filter the dimension and let propagation handle the fact.

Bidirectional relationships. Bidirectional cross filtering plus RLS is a known source of both performance problems and leakage. Use CROSSFILTER inside specific measures rather than turning it on model wide.

Dynamic RLS on a stale mapping table. USERPRINCIPALNAME() against a user to territory mapping is the standard pattern, and it is only as correct as the mapping, which is usually fed by HR data nobody has validated in a year.

No test procedure. "View as role" in Desktop tests the DAX. It does not test service side assignment, group nesting, or a user in two roles, since roles are additive and overlapping roles widen access. Build a short test matrix of representative users and rerun it after every material change. Then schedule a quarterly access review across app audiences, workspace roles, RLS memberships and direct shares.

Power BI Report Server: where on premises still makes sense

Power BI Report Server is a separate product from the service: an on premises server, an evolution of SQL Server Reporting Services, hosting paginated reports, mobile reports, KPIs and a restricted flavour of Power BI reports. It is licensed through Power BI Premium or Fabric capacity, or a SQL Server Enterprise licence with Software Assurance.

Where Power BI report server genuinely fits:

• A regulatory, contractual or sovereignty requirement that data does not leave your network.
• An air gapped or heavily restricted network where the service is not reachable.
• A large SSRS estate where thousands of paginated reports run and rewriting has no business case.
• Operational document generation at volume: statements, invoices, compliance packs.

Where it does not fit:

• If you want current features. Report Server ships on a slower cadence and lacks large parts of the modern service, including dataflows, most AI visuals, Copilot, apps and much of the collaboration surface.
• If you want low maintenance. You own the server, the SQL backend, patching, backups and high availability.
• If you need Direct Lake or Fabric items, since investment is concentrated in the cloud service.

Hybrid is common and reasonable: Report Server for paginated and operational documents plus anything that cannot leave the perimeter, the cloud service for interactive analytics. If you go hybrid, be explicit about which system is authoritative for which numbers, because two platforms with overlapping scope is how you end up with two versions of revenue.

The reports nobody opens, and what to do about them

Every mature tenant accumulates a long tail: reports built for a project that ended, dashboards made for an executive who moved on, models refreshing eight times a day to serve zero queries. They cost capacity, add gateway load, clutter search and create risk, because old reports carry old RLS assumptions.

The per workspace usage metrics report gives views, unique viewers and trend. On capacity, the admin API and activity log give a tenant wide picture. Pull it once and the results are usually stark. A workable retirement process:

1. Every published report gets a named owner and a review date. No owner means no publish.
2. Quarterly, list reports below a threshold of unique viewers over 90 days.
3. Mail the owner. Either they justify it in a sentence or it moves to an archive workspace.
4. Turn refresh off on archived items immediately, which alone often recovers capacity, then delete after a quarter. Keep the .pbix in source control if you want an undo.

The hard part is political. Frame retirement as protecting the reports that matter: when there are 40 reports and 6 are trusted, nobody knows which 6.

Where Skopx fits with Power BI reports, and where it does not

Directly, because vague positioning helps nobody: Skopx does not build Power BI reports, does not host them, does not replace a semantic model, and is not a BI platform. It is not a data warehouse and not an ETL tool. If you need governed dashboards over a modelled warehouse, you need Power BI or a peer product, and everything above stands unchanged.

The honest overlap is narrower. A large share of the traffic hitting most Power BI reports is not analysis, it is lookups: "what did EMEA close last month," "did that invoice get paid," "which accounts renewed this quarter." Those get answered by building another report page, which joins the long tail and stops being opened. That is a distribution problem more than a modelling one.

Skopx is an AI workspace connecting nearly 1,000 tools a company already uses, including Gmail, Slack, Stripe, HubSpot, QuickBooks and Google Analytics. It handles the recurring question pattern three ways: chat that answers in plain language with the underlying records cited, pulled live from connected systems; a morning brief summarising what changed before the day starts; and an insights engine plus workflows that surface risks and run described routines on a schedule.

Weekly revenue question, answered before it is asked

Monday 08:00

Runs before the weekly meeting

Pull billing data

New, expanded and churned revenue

Pull CRM pipeline

Closed won and stage changes

Compare to prior week

Flag movements beyond a threshold

Write the summary

Plain language, each figure cited to its record

Post to the channel

Everyone reads the same numbers

Two limits, plainly. Skopx answers from the systems it connects to, not from your semantic model, so a metric with a careful DAX definition lives in Power BI and should stay there. And anything needing a governed, audited, visually precise artifact, a board pack, a filing, an embedded customer chart, is a BI tool's job.

Skopx pricing is Solo at $5 per month and Team at $16 per seat per month, with BYOK: bring your own AI key for any major model, zero markup. Security posture is SOC 2 controls in place, not a stronger claim. The point is not to compare that to a BI licence, because they are not substitutes, but to make the trade legible: keep Power BI for governed reporting, and stop building report pages whose only purpose is answering a question somebody could just ask.

The same "the tool is fine, the process around it is not" pattern shows up well outside analytics, in CRM for Nonprofits: Donor Management Options Compared and Supply Chain Data Collection Tools for Messy Inputs.

Frequently asked questions

What is the difference between Power BI reports and dashboards?

A report is multi page and interactive, built on one semantic model, with cross filtering, slicers and drillthrough. A dashboard is a single page of tiles pinned from one or more reports, with no cross filtering between tiles, and it can only be created in the service. Most modern deployments distribute a report page inside an app and skip dashboards. The power bi reports vs dashboards distinction matters most when someone asks for a feature the object cannot support.

How often can Power BI reports refresh?

Import mode models on a Pro workspace can be scheduled up to eight times a day. On Premium or Fabric capacity that rises to 48, with the XMLA endpoint and the enhanced refresh API for finer control. DirectQuery and Direct Lake do not refresh on a schedule in the same sense, because they read at query time. If you need near real time, plan the storage mode around it rather than scheduling your way there.

Do people need a licence to view a Power BI report I share?

Usually yes. A Pro licence is required to view content in a standard workspace. The exception is a workspace backed by Premium or Fabric capacity, where users on a free licence can view items published in an app. Publish to web needs no licence because it is anonymous and public, which is exactly why it should be locked down at tenant level.

When should I use Power BI Report Server instead of the cloud service?

Choose Power BI report server when data genuinely cannot leave your network, when you are on a restricted or air gapped network, when you have a large existing SSRS estate, or when the workload is high volume document generation. Choose the cloud service for everything else, particularly if you want current features, Fabric integration or lower operational overhead.

Why does row level security sometimes not apply?

The most frequent cause is workspace membership: users with Member or Admin rights bypass RLS on models in that workspace. Other causes are roles with no members assigned in the service, filters applied to the fact table but not the dimensions feeding slicers, and users in two roles, since roles are additive and combine to widen access. Test in the service with representative accounts, not only with "view as role" in Desktop.

How do I stop building reports nobody opens?

Require a named owner and a review date before publication, then use the usage metrics report quarterly to find items with almost no unique viewers over 90 days. Ask the owner to justify or archive, turn refresh off on archived items straight away, and delete after a quarter. Separately, notice which requests are lookups rather than analysis: those are better served by a question and answer surface or a scheduled brief than by a new report page.