Power BI Report Settings - The Toggles Most Teams Never Touch

There is a small gear icon in Power BI report settings that almost nobody opens on purpose. Most reports get published with whatever defaults were in place, and the settings only get looked at when something has already gone wrong. A user complains they cannot filter the report the way they expect. Someone on an iPad gets a cramped desktop layout crammed onto a small screen. A tooltip that should explain a chart just is not appearing. Nine times out of ten the cause is a report setting nobody consciously chose, and the fix is a toggle in a panel people forget exists.

I want to walk through the report settings that actually matter, because getting them right is cheap and getting them wrong quietly costs you support tickets and user trust. Microsoft's documentation on report settings has the exhaustive list. This is the consultant's version: which ones to care about and why.

Where these settings even live

First, a bit of orientation, because Power BI has settings in several places and it is easy to look in the wrong one. There are settings in Power BI Desktop under Options, which affect how the tool behaves for you. There are tenant settings in the admin portal, which govern the whole organisation. And then there are report settings, which travel with the specific report and apply to everyone who views it.

The report settings are the ones this is about. In Desktop you find them under File, then Options and settings, then Options, in the Current File section. In the Power BI service you open the report, go into settings, and adjust them there. The important thing to understand is that these are per-report. Set them once for a report and they stick to that report wherever it goes, which is exactly why an unconsidered default can follow a report all the way into production.

The settings that actually earn their keep

Let me go through the ones worth a deliberate decision rather than listing all of them.

Persistent filters. By default, Power BI remembers the filter and slicer changes a user makes and restores them next time they open the report. This is usually what you want, because it feels considerate, the report comes back the way the user left it. But it causes a specific and confusing support pattern. A user filters down to one region, forgets, comes back a week later, sees only that region's numbers and reports that "the data is missing". There is a "reset to default" option they never use. For an executive dashboard where you want everyone seeing the same complete picture, turning persistent filters off can save you a genuinely baffling round of support conversations. Decide this one on purpose.

Cross-report drillthrough. This lets a report pass filter context to a completely separate report when a user drills through. It is off by default and it is quietly one of the more useful features once you have a suite of reports rather than a single one. A sales overview can drill straight into a detailed customer report carrying the selected customer with it. If you are building a connected set of reports, this is worth switching on. If you have one standalone report, ignore it.

Personalise visuals. This allows report readers to change a visual for themselves, swap the chart type, change what is measured, without editing the report for everyone else. My honest opinion is that this one splits people. Given to a data-literate audience it is genuinely handy and cuts down "can you also show me this as a line chart" requests. Given to a general audience it produces confusion, because people change things, forget they changed them, and then report that the chart is broken. Match it to your audience rather than turning it on by reflex.

Tooltips and the modern visual tooltips setting. Tooltips are one of the highest-value, lowest-effort things in a report, and the settings around them are worth checking. Well-built tooltips let you add context and detail without cluttering the main view, and the modern tooltip options give you more control over how they render. If your carefully built report-page tooltips are not showing up, this settings area is the first place to look.

Default summarisation and the smaller data toggles. There is a cluster of settings about how data is handled that are easy to skim past and occasionally important, things governing how visuals interact and how relationships are treated. You will not touch most of these on most reports, but when a report is behaving oddly and the DAX all looks correct, this panel is worth a scan before you tear the model apart looking for a bug that is actually a setting.

Mobile is a setting decision people forget

Here is a mistake I see constantly. A report gets built on a wide monitor, it looks great, it ships. Then a big chunk of the audience opens it on a phone and gets the desktop layout shrunk down to something unusable, tiny text, charts they have to pinch and pan around.

The mobile-optimised layout is a deliberate piece of work, not a setting you flip, but it starts from the decision to consider mobile at all. If a meaningful share of your readers are on phones, and for a lot of Australian field-based businesses they absolutely are, someone standing on a site or in a warehouse rather than at a desk, then building a mobile layout is not optional. It is part of the job. Deciding to skip it should be a conscious choice based on knowing your audience, not something that happens because nobody thought about it.

This is one of those areas where a bit of upfront thinking about who reads the report and on what device saves a lot of grief later. We spend a fair bit of time on exactly this sort of thing in our Power BI work, because a technically correct report that is painful to actually use on the device people hold is a report that does not get used.

Treat settings as part of a standard, not a one-off

The bigger lesson from years of doing this is that report settings should not be a per-report improvisation. They should be part of a house style.

When every report in an organisation makes its own independent choices about persistent filters, personalisation and the rest, you get an inconsistent experience where one report remembers your filters and the next does not, and users cannot build a reliable mental model of how "the reports" behave. That inconsistency is a quiet tax on everyone who uses them. It reads as sloppiness even when each individual report is fine.

The organisations that get real value from Power BI at scale tend to have a documented set of defaults. Persistent filters off for executive dashboards, on for analytical tools. Personalisation on only for the analyst-facing reports. A mobile layout mandatory for anything a field team will open. Written down, applied consistently, reviewed when a report is built. It is not exciting work and it is exactly the kind of standard that separates a mature Power BI practice from a pile of reports that happened to accumulate. This is a core part of the governance and enablement side of getting Power BI right, and it is usually the piece that has been skipped when a client's reporting feels chaotic.

Small toggles, real consequences

None of these settings are difficult. That is exactly why they get ignored, and why ignoring them costs more than you would expect. Five minutes of deliberate decisions when a report is built saves hours of support conversations, and it makes the difference between a report that feels considered and one that feels like it was thrown together.

Go and open the settings panel on your most important report today and actually read what is switched on. I would bet at least one of them is set to a default nobody chose, and fixing it is a two-minute job that quietly improves things for everyone who opens that report.

If your reporting has grown into a sprawl of inconsistent reports and you want to bring some order to it, or you are standing up a Power BI practice and want the standards right from the start, that is the kind of work we do. Take a look at our services or get in touch for a straight assessment.

For the full list of every setting and exactly where to find it, Microsoft's report settings documentation is the reference to keep handy.