ALL() Not behaving as expected

Hi LukeTempleton 

The behavior you’re seeing isn’t random. It happens because both of your measures rely on columns from the fact table, and a fact table is never a stable source for a “static” list of items. Any filter that removes rows in the fact table—date, category, other slicers, bi-directional relationships, page filters—will also remove clinics from the DISTINCT list. That’s exactly why your denominator jumps from 135 to 56/129 depending on which clinic is selected.

What your measures really do
COUNT_OF_CLINICS =
CALCULATE(
DISTINCTCOUNT(FACT_TABLE[CLINIC]),
ALL(FACT_TABLE[CLINIC], FACT_TABLE[CLINIC_SORT])
)

ALL() here removes filters only from the CLINIC columns. Everything else stays: page filters, relationships, cross-filtering.
So this measure returns:

“How many clinics still have rows after all other filters—except the slicer—are applied.”

That’s why Clinic A gives 56, Clinic B gives 129, and A+B gives 135.
Each clinic interacts differently with the rest of your filters, so different sets of rows survive → different denominators.

Your numerator is fine; it simply counts what’s selected. The denominator is the one that can’t behave predictably when it’s based on a fact table.

The clean fix: use a proper Clinics dimension table

This immediately makes the denominator stable.

Create a dimension:

DIM_Clinic =
DISTINCT(FACT_TABLE[CLINIC])

Relate DIM_Clinic → FACT_TABLE.

Use DIM_Clinic[CLINIC] in the slicer.

Rewrite the measures:

COUNT_OF_SELECTED_CLINICS :=
DISTINCTCOUNT(DIM_Clinic[CLINIC])

COUNT_OF_CLINICS :=
CALCULATE(
DISTINCTCOUNT(DIM_Clinic[CLINIC]),
ALL(DIM_Clinic)
)

Now the denominator becomes what you actually want:
“How many clinics exist after page/report filters, regardless of current slicer selection.”

No more jumps. No more mystery.

If you can’t add a dimension table

You can try to stabilize the denominator, but the fact table will always be sensitive to other filters. So it may work in some scenarios, but it will never be bulletproof.

To move forward

At this point, to understand the exact filter interaction causing your 56/129/135 swings, I really need a small mocked-up PBIX with the same structure.
It doesn’t have to be your real data.
You can generate 30–50 fake rows (even via AI tools) that follow the same model structure and slicer logic.

A tiny reproducible example will allow giving you a precise, targeted fix instead of guessing how filters propagate in your model.

If this post helps, then please consider Accepting it as the solution to help the other members find it more quickly