Apply All and Clear All Slicers Buttons in Power BI - The Cheapest Performance Win You're Not Using

Every consulting engagement that starts with "our Power BI reports are slow" follows a familiar script. We open the report, and there they are: seven slicers down the left side, a dozen visuals on the canvas, and a DirectQuery connection back to a database that's already having a hard week. The user picks a state, waits. Picks a date range, waits. Picks a product category, waits again. Three selections, three full rounds of every visual on the page re-querying the source, and only the last round actually mattered.

There's a button for this. Two, actually. The Apply all slicers and Clear all slicers buttons have been sitting in Power BI for a while now, and they remain one of the most underused performance features in the product. I want to walk through what they do, how to set them up properly, and the sharp edges we've found putting them into production reports, because the official documentation covers the how but is politely quiet about the when and the why-not.

The maths of wasted queries

The core problem is that slicers apply instantly by default. Every individual selection triggers every other visual on the page to re-query. That's lovely when you have two slicers and a fast import-mode model. It's brutal when you have five slicers and a DirectQuery source.

Microsoft's own worked example in the docs is worth repeating because the numbers are stark. Five slicers, six other visuals. A user makes eleven individual selections across those slicers before they've described the filter state they actually want. Ten of those selections triggered updates the user never looked at - that's 60 visual queries fired at your source for nothing. With an Apply all slicers button, the slicers batch up in a pending state, the user clicks Apply once, and you're down to the six queries that matter.

On an import model with a well-built star schema, you might shrug at this. On DirectQuery against an operational database, or against a Fabric warehouse where every query burns capacity units, this is real money and real user patience. One retail client of ours had a store operations report where the morning rush of area managers all filtering to their own stores was producing a measurable load spike on the source. Adding an Apply button flattened it. Total development effort: about four minutes.

Setting them up

Creation is genuinely trivial. In Power BI Desktop, go to the Insert ribbon, select Buttons, and pick Apply all slicers from the dropdown. Same path in the Service if you're editing there. The Clear all slicers button lives in the same menu. After that they're ordinary buttons - style them, position them, put them wherever your slicers live.

Clear all is more useful than it first appears, and for the same query-reduction reason. Clearing five slicers one at a time using each slicer's own clear control fires a full page refresh after each of the first four clears - two dozen pointless queries before you reach the state you wanted. The button clears everything, then refreshes once.

Once an Apply button is on the page, slicer behaviour changes. Selections no longer apply instantly; slicers sit in a pending state, shown by a small clock icon in the slicer header with some customisable text. You can restyle the pending icon's colour, size, and position in the formatting pane, or hide it, but you can't swap the icon itself.

The bookmark trick for letting users choose

Here's a pattern from the docs that I have mixed feelings about but that some report audiences genuinely love: you can let users toggle between batched and instant slicer behaviour using bookmarks.

The mechanics: create one bookmark with the Apply button visible and another with it hidden, both scoped to selected visuals only, then surface the pair through a bookmark navigator. When the last Apply all slicers button on a page is hidden, the slicers revert to applying instantly. So the two bookmarks effectively become a mode switch - "batch my selections" versus "apply as I click."

It works. The docs even specify a rather charming trapezoid tab design for the navigator, down to the pixel padding. But be honest with yourself about whether your audience needs it. Every mode switch you add to a report is something a user can be confused by, and we've watched plenty of session recordings where a user toggled something without understanding what changed. For most reports I'd pick one behaviour, based on how expensive the queries are, and commit. Save the toggle for analyst-heavy audiences who'll actually appreciate having the choice.

The gotchas, from experience

A few things that will catch you, most of which we learned the mildly annoying way on client work through our Power BI consulting practice.

The buttons are page-wide, full stop. You cannot scope an Apply button to a subset of slicers. Every slicer on the page batches, or none do. You can place multiple buttons on the page - handy when slicers live in two separate visual sections - but pressing any of them applies everything. If you have a design where one slicer should apply instantly (say, a coarse region filter) and others should batch, this feature can't express that. Redesign the page or accept the compromise.

They don't touch the Filters pane. Anything a user does in the Filters pane still applies instantly. If your report leans on the pane for user-driven filtering, the Apply button gives you less than the query maths above suggests.

The pending state disappears with the slicer header. If you've turned slicer headers off for visual cleanliness - and plenty of designers do - there is no indication on the slicer that a selection is pending. The only signal left is that the Apply button switches from disabled to enabled. That's subtle enough that users will make selections, see nothing change, and conclude the report is broken. If you use these buttons, leave the headers on. This one produced an actual support ticket for us before we worked out what the user was seeing.

Custom visuals complicate things. If the page mixes native slicers with custom filter visuals, pressing Clear all slicers can require a follow-up press of Apply all slicers before everything settles into the default state. Test this combination specifically before shipping, because the interim state looks like a bug even when it's documented behaviour.

And a design note rather than a limitation: a pending-selection model changes how people read the page. Users glance at visuals assuming they reflect the slicers next to them. With batching, that assumption breaks between selection and apply. Keep the Apply button visually adjacent to the slicers, make it prominent, and if the audience is non-technical, a one-line text box ("Select filters, then press Apply") saves you a surprising amount of confusion.

When to reach for this

My rule of thumb after a few years of these: any DirectQuery report with three or more slicers should have an Apply all slicers button by default, and you should need a reason not to add one. For import-mode reports it's situational - if the model is fast, instant slicers are a nicer experience and the batching just adds a click.

The other trigger is Fabric capacity. Now that so many of our clients run Power BI on Fabric capacities, wasted visual queries are no longer just a UX problem - they're consumption you pay for. Query reduction features have quietly gone from "nice for performance" to "part of your capacity cost management," and this button is the easiest of the lot. It pairs with the broader capacity tuning we do in Microsoft Fabric engagements, where slicer-happy report pages regularly show up as unexpected line items in the capacity metrics app.

None of this fixes a bad model, of course. If your report is slow with one filter applied, batching filters won't save you - that's a modelling or source problem, and no button will out-run a missing aggregation table. But for the specific, common problem of chatty slicer pages hammering a source with queries nobody looks at, this is four minutes of work for a very visible win.

If your reports have crossed the line from "a bit slow" to "people export to Excel to avoid using them," that's usually a sign the problems run deeper than slicers - we can help with that.