Why a “simple” taxonomy refiner has been a feature request… for years

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:

1. Load the term set from the Term Store

2. Use it as the structure

3. 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.