Why a “simple” taxonomy refiner has been a feature request… for years
- Introduction
- The Five Guys conversation 🍔
- The feature request
- How filters in PnP Modern Search actually work
- The core problem: search vs taxonomy
- Why taxonomy refiners don’t “just work”
- The workaround: static + hybrid approach
- Visualising the difference
- Making it more usable
- What’s next
- Final takeaway
- About the author
Contents
- Introduction
- The Five Guys conversation 🍔
- The feature request
- How filters in PnP Modern Search actually work
- The core problem: search vs taxonomy
- Why taxonomy refiners don’t “just work”
- The workaround: static + hybrid approach
- Visualising the difference
- Making it more usable
- What’s next
- Final takeaway
- About the author
Introduction
There are some feature requests that just never seem to go away.
This is one of them.
👉 “Can we just have a taxonomy refiner that behaves like the Term Store?”
If you’ve worked with SharePoint search, PnP Modern Search, or tried to build a proper filtering experience—you’ve probably run into this.
And if you haven’t… you will 😄
The Five Guys conversation 🍔
At MVP Summit 2025, I had one of those conversations you only really get at events like this—this time over burgers at Five Guys.
I was sitting with Franck Cornu, the original creator of PnP Modern Search, and we ended up talking about this exact feature request from 2011.
You know the one:
“Give me a hierarchical taxonomy refiner that behaves like the term set—full structure, parent/child relationships, proper filtering.”
Simple on paper.
And then Franck said:
“Yeah… that’s a hard nut to crack.”
That stuck with me.
Because it reframes the entire discussion ( and turned it into a a challenge for me )
👉 This isn’t a missing feature—it’s a structural challenge.
The feature request
If you look at the long-running discussions, it boils down to:
Show the term set as a tree in the filter— and make it behave like users expect
- Parent/child hierarchy
- Selecting a parent includes children
- Aggregated counts
- Full structure visible
Sounds obvious.But it clashes directly with how search actually works.
How filters in PnP Modern Search actually work
The Search Filters web part is not a data source.
It is simply a projection of the search query result.
Which means:
- It reads values from the search results
- It aggregates values dynamically
- It only shows what the search API returns
So in practice:
Filters reflect what is in the result set, not what exists in your taxonomy
The core problem: search vs taxonomy
At the heart of the issue is a mismatch between two models.
Search refiners are:
- Dynamic
- Result-driven
- Aggregated
- Flat
Term sets are:
- Static
- Authoritative
- Hierarchical
- Structured
Search knows:
- Which terms are used
But not:
- The full hierarchy in a usable way
Why taxonomy refiners don’t “just work”
When you try to apply taxonomy to refiners:
- Terms without results disappear
- Hierarchy is flattened
- Parent/child relationships are lost
Even the hierarchical refiner approach:
- Uses the term set for structure
- But still depends on search for values
👉 The hierarchy is reconstructed—not provided by search.
The workaround: static + hybrid approach
To bridge the gap, the model becomes:
- Load the term set from the Term Store
- Use it as the structure
- Match search results against it
So instead of:
Search → structure + values
You get:
Term Store → structureSearch → matching
Visualising the difference
You can think of the three approaches like this:
1. Search-driven refiner (classic)
- Search → aggregation → filter values
- Flat and dynamic
- No hierarchy
2. Taxonomy-driven refiner (static)
- Term Store → full tree
- Complete hierarchy
- No relation to current results
3. Hybrid refiner (PnP Modern Search today)
- Term set → structure
- Search → matching values
- Tree is filtered based on results
👉 This is the model we are working with today.
Making it more usable
One of the biggest UX challenges with the hybrid approach has been:
- Showing the full term set
- Even when large parts don’t apply
This leads to:
- Empty branches
- Filters that return no results
A recent improvement addresses this by allowing:
✅ Hide nodes not in the currect data set
What that changes
Instead of always rendering the full tree:
- The structure still comes from the term set
- But visibility is now influenced by the result set
So the refiner becomes:
- Cleaner
- More relevant
- Easier to navigate
👉 It feels more dynamic—without actually changing the underlying model
What’s next
One thing that is still missing—and that I expect (and hope) will come—is:
🔜 Multi-selection across the hierarchy
Because today only single selection is available and adding multi selection opens brand new can of worms, like “can parent and child be selected together?” and “How should the current selection be displayed for both AND and OR?”
There’s no obvious answer—and each choice affects how queries are constructed.
I’d love your feedback 👇
This is very much an evolving space, and I’d love input from others working with search and taxonomy.
- How should multi-selection behave in a tree?
- Where does the current approach fall short?
Final takeaway
This feature request has been around for years—not because it’s been ignored.
But because it sits right at the boundary of what the platform supports.
Refiners are aggregations. Taxonomy is structure.
Bringing those two together is possible—but only through trade-offs.
And what we have today is essentially a carefully balanced hybrid.
About the author
Kasper Larsen
K, Larsen (27/10/2026) Why a “simple” taxonomy refiner has been a feature request… for years
