Power BI Slicers With Multiple Fields - Building Hierarchies Without Clutter
There's a small Power BI feature I keep forgetting to mention to clients, and every time I show it to them they ask why they didn't know about it three years ago. You can add more than one field to a single slicer. The result is a tree-style slicer that lets users drill from a broader category into a more specific one, all without taking up half the page with stacked filters.
If you've ever built a report that needed a Country filter, then a State filter, then a City filter, you've felt the pain. Three slicers down the side of the page, each one cross-filtering the others, each one taking up space you don't have. A multi-field slicer collapses that into one. The user expands Australia, sees the states, expands New South Wales, sees the cities. Same data, one third of the real estate.
This post is the short, practical version. What it does, where it pays off, where it fails, and a few small tricks I've picked up.
How it works
You drop a slicer onto the canvas. You drag your first field (say, Country) into the Field well. Then you drag a second field (State) into the same well. Power BI builds a hierarchy slicer. The user sees Country at the top, with little expand arrows next to each value. Expanding pulls in the State values for that country.
You can stack as many fields as you want. Country, State, City, Suburb. The slicer respects the order you put them in. You can change the order by dragging the fields up and down in the Field well.
The selection model is what makes it useful. The user can select a value at any level. Select "Australia" at the top and you've filtered by country. Expand Australia and select "Queensland" and you've filtered by state. Expand Queensland and tick a few cities and you've selected those specific cities. The slicer always shows you which levels have selections active, so you don't get lost.
It works with any field combination as long as the fields are in the same table or related through the model. You don't need a formal hierarchy defined in the data model, though if you have one you can drag the whole hierarchy into the well in a single step.
Where this saves you space and complexity
Geographic filters are the obvious one. Anything with a Country/State/City pattern is a candidate.
Org structures are the other big one. Division, Department, Team, Individual. We rebuilt a workforce reporting model for a state government client last year where the existing report had four slicers stacked on top of each other for the org breakdown. Users hated it because the cross-filtering felt unpredictable. We collapsed it into one hierarchy slicer and the complaints stopped within a week. Same data, much better feel.
Product hierarchies work too. Category, Subcategory, Product. Account hierarchies. Date hierarchies (Year, Quarter, Month) when you want the user to pick a specific period rather than use a date range slicer.
The pattern that doesn't work as well is filters that aren't really a hierarchy. Sales Channel and Customer Segment, for example, don't have a parent-child relationship, so putting them in the same slicer just looks confusing. Use two separate slicers there.
This is one of those small UX improvements that adds up across a report. On a typical dashboard we'll save two or three slicers worth of space, which is enough to fit another visual on the page. We use this on most of the dashboards we build for Power BI consulting clients, especially exec-facing pages where every pixel counts.
A few small tricks
Sort order matters more than you'd think. Power BI sorts each level of the slicer by the field's default sort. For most fields that's alphabetical. For dates and quarters you probably want a custom sort by a numeric key. Set this up in your model with a sort-by column before you build the slicer. Otherwise you'll get Q1, Q2, Q3, Q4 alphabetised correctly, but months will go alphabetically (April, August, December) which is useless.
Search across all levels. The hierarchy slicer has a search box. The search box looks across every level you've added. Type "Sydney" and the slicer will show you the Sydney entries even if they're three levels deep. This is a great affordance for users who know what they're looking for and don't want to click through layers.
Multi-select at any level. Hold Ctrl, select multiple values at any level (or across levels), and the slicer treats them as an OR filter. So you can have Queensland selected at the state level and Bondi selected at the city level, and the report will show data for all of Queensland plus the Bondi suburb. Useful for "I want to see my home state and these specific other locations" patterns.
Format the slicer to look like a slicer. The default styling of a hierarchy slicer is the same dropdown look as a regular slicer. If you have it on a page with other filters, give it a header that makes the hierarchy nature obvious. Something like "Location (drill down to see suburbs)" works better than just "Location" because it cues the user to use the expand arrows.
Mind the cross-filtering with other visuals. A hierarchy slicer cross-filters the same way a regular slicer does. If you have a Country/State/City slicer next to a Region slicer that isn't part of the same hierarchy, you can get into weird states where the user has selected Australia and Region A and the chart is empty because Region A doesn't include any Australian data. Test these interactions before you ship.
Where it falls over
Performance can be a surprise on very wide hierarchies. If you put a Customer field at the bottom of a four-level hierarchy and you have half a million customers, the slicer will be slow to expand to that level. Power BI does some lazy loading, but if you're hitting a Direct Query source you'll feel every query the slicer fires. For very large bottom levels, consider using a search-only pattern (a regular text slicer set to search mode) and keep the hierarchy slicer for the upper levels.
Bookmarks and the hierarchy slicer can get awkward. If you build a bookmark that captures a specific selection in a hierarchy slicer, restoring that bookmark works fine. But if you've changed the underlying data (added new countries, for example) since the bookmark was saved, the restored state can look weird. Test bookmarks after data changes if your report has them.
Mobile layout is not great. The hierarchy slicer expands inline on desktop. On the mobile layout it tries to render in a smaller space and the expand arrows can be hard to hit. If you're building for mobile-first, test it on a phone before assuming the desktop experience will carry over. Sometimes a regular dropdown slicer per level is more thumb-friendly.
It only works with categorical data. You can't put a measure or a continuous variable in a hierarchy slicer. That's fine because you wouldn't want to, but I've had a few clients ask "can I have a numeric range hierarchy" and the answer is no.
When to use it versus the alternatives
If you have a true parent-child relationship in your data, use a hierarchy slicer. It's almost always cleaner than three separate slicers.
If you have unrelated filters, keep them separate. Don't force them into a hierarchy just to save space.
If you want a drill-through experience instead of an in-place filter, that's the Power BI drillthrough feature, which is a different pattern and worth knowing about separately. Drillthrough takes you to a new page filtered to the selection. Hierarchy slicers filter the current page.
If the user really wants to pick a specific value from a long list (a specific customer, a specific SKU), a dropdown slicer with search is usually better than expanding through three levels of hierarchy. The hierarchy slicer is best when the user is browsing the structure, not searching for a known leaf node.
The cleanup pattern that usually works
Walk through your existing reports. Anywhere you see two or three slicers stacked on top of each other and they happen to represent a Country/State/City or Division/Team/Person style relationship, you've got a candidate. The refactor takes about ten minutes per slicer set. Replace the stack with a hierarchy slicer, adjust the layout to use the reclaimed space, and test the cross-filtering with the rest of the page.
The users almost never notice the change, which is the highest compliment a UX change can get. They just find the report easier to use without being able to articulate why.
If you want help thinking through a broader report cleanup or you're moving into Microsoft Fabric and reconsidering your reporting model, that's the kind of work we do across most of our business intelligence projects at Team 400. Small features like the hierarchy slicer add up. A well-designed slicer set is often the difference between a report users open daily and a report users avoid.
For the official Microsoft write-up, see the Power BI hierarchy slicer documentation. It's a short page. Worth bookmarking the next time someone on your team asks "how do I make this report less cluttered".