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

Thank you all for your replies! Unfortunately my employer has asked me to shift attention to a different project for a while, so I don't have time right now to engage further with this topic. I will try to post some sample data when I get a chance. Thanks again!

hello LukeTempleton 

without your sample data, it is hard to image what your table looks like. you can share a partial of your sample data so experts pbi can give you an insight.

apart from that, i recreate a simple example based on your description (it might be not accurate since i dont know how your table is).

1. sample data has 6 numerator and 6 denumerator of distinct count of column ID. There are AAA, BBB, CCC, DDD, EEE, and FFF.

2. when selected clinic A, numerator and denumerator is 3 because there are AAA, BBB, and CCC in ID column

Numerator =
CALCULATE(
    DISTINCTCOUNT('Table'[ID]),
    ALLSELECTED('Table'[ID])
)

Denumerator =
CALCULATE(
    DISTINCTCOUNT('Table'[ID]),
    ALL('Table'[ID])
)

Hi LukeTempleton,

Thank you so much for tour replies to the query Ritaf1983 and Irwan and continue using Microsoft Fabric Community Forum

Since we haven't heard back from you yet, I'd like to confirm if you've successfully resolved this issue or if you need further help?

If you still have any questions or need more support, please feel free to let us know. 

We are more than happy to continue to help you.

Hi LukeTempleton 

Key facts
✔ Single fact table
✔ Clinic slicer uses FACT_TABLE[CLINIC]
✔ Page-level filters exist (not on Clinic)
✔ No separate Clinic dimension table
✔ CLINIC_SORT is involved (important!)

Root cause
ALL(FACT_TABLE[CLINIC], FACT_TABLE[CLINIC_SORT])does NOT:
“Return the total number of clinics in the slicer”

It actually:
Removes filters only from those two columns and keeps row-level filtering caused by the fact table itself

Why that causes your issue?
When you select:
Clinic A only
Fact table is reduced to rows for Clinic A
Some other clinics do not exist in the remaining rows
ALL() cannot “bring back” rows that are already gone

So:
Clinic A → fact table only has rows for clinics that co-occur with A
Clinic B → different row set → different clinic count
A + B → broader row set → larger clinic count

Hence, denominator changes depending on selection, even though you used ALL()
This is expected behavior in a single-fact-table model.

Solution:
Create a Clinic Dimension Table
DimClinic =
DISTINCT (
SELECTCOLUMNS (
FACT_TABLE,
"Clinic", FACT_TABLE[CLINIC],
"ClinicSort", FACT_TABLE[CLINIC_SORT]
)
)
Use DimClinic[Clinic] in the slicer

Create a relationship:
DimClinic[Clinic] → FACT_TABLE[CLINIC]

Measures after fixing the model
Numerator (selected clinics)
COUNT_OF_SELECTED_CLINICS =
DISTINCTCOUNT ( DimClinic[Clinic] )

Denominator (total clinics after page filters)
COUNT_OF_CLINICS =
CALCULATE (
DISTINCTCOUNT ( DimClinic[Clinic] ),
ALL ( DimClinic )
)

If you absolutely CANNOT create a dimension table

COUNT_OF_CLINICS =
CALCULATE (
DISTINCTCOUNT ( FACT_TABLE[CLINIC] ),
REMOVEFILTERS ( FACT_TABLE ),
VALUES ( FACT_TABLE[CLINIC] )
)

ALL() cannot recover rows that no longer exist in the filter context. Only a dimension table gives you a truly static denominator.