count distinct

Hi Gianpie 

Can you try this 

Count_Items_To_Process =

VAR LimitDate = [CurrentDateMinus1]

RETURN

CALCULATE(DISTINCTCOUNT( Activity_Log[ItemID]),KEEPFILTERS(

FILTER(Dim_Items,

Dim_Items[Status] IN { "Approved", "Started" }

&& Dim_Items[GoLiveDate] < LimitDate

&& [% Progress Ratio] > 0.9)))

Hi,

As per our understanding your issue, the reason your refactored measure returns blanks is due to how filter context and variables behave inside CALCULATE() in Microsoft Power BI.

Your original measure works because:

FILTER(Dim_Items, ...)

creates a row context over Dim_Items.

But in your optimized version:

VAR ProgressVal = [% Progress Ratio]

the measure is evaluated only once in the outer filter context, not per row of Dim_Items.

So this condition:

ProgressVal > 0.9

becomes a single scalar evaluation instead of a row-by-row filter.

That’s why you get blanks or incorrect results.

Correct Optimization Pattern

You should keep the row-wise filtering inside FILTER() while still using variables for reusable scalar values.

Try this:

Count_Items_To_Process_v2 =
VAR LimitDate =
    [CurrentDateMinus1]

RETURN
CALCULATE(
    DISTINCTCOUNT(Activity_Log[ItemID]),
    FILTER(
        Dim_Items,
        Dim_Items[Status] IN {"Approved","Started"} &&
        Dim_Items[GoLiveDate] < LimitDate &&
        [% Progress Ratio] > 0.9
    )
)

Why this works

Inside:

FILTER(Dim_Items, ...)

Power BI evaluates:

• each row of Dim_Items
• along with context transition from the measure

So:

[% Progress Ratio]

is recalculated correctly per row context.

Important Concept

This is the key difference:

Performance Optimization Tip

If [% Progress Ratio] is expensive:

• consider materializing part of the logic as a calculated column
• OR pre-aggregating in Power Query/model

because measures inside FILTER() over large dimensions can still be costly.

You can also write:

Count_Items_To_Process_v2 =
VAR LimitDate =
    [CurrentDateMinus1]

RETURN
CALCULATE(
    DISTINCTCOUNT(Activity_Log[ItemID]),
    KEEPFILTERS(
        FILTER(
            Dim_Items,
            Dim_Items[Status] IN {"Approved","Started"} &&
            Dim_Items[GoLiveDate] < LimitDate &&
            [% Progress Ratio] > 0.9
        )
    )
)

This preserves existing filters more safely.

Hope this helps.

Thanks!

Gianpie 

you can try this

Count_Items_To_Process_v3 :=
VAR LimitDate =
[CurrentDateMinus1]
RETURN
CALCULATE(
DISTINCTCOUNT(Activity_Log[ItemID]),
KEEPFILTERS( Dim_Items[Status] IN { "Approved", "Started" } ),
KEEPFILTERS( Dim_Items[GoLiveDate] < LimitDate ),
KEEPFILTERS(
FILTER(
Dim_Items,
[% Progress Ratio] > 0.9
)
)
)

if this does not work, pls provide some sample data and expected output

Hi Gianpie 

As a general rule, it’s better to filter specific columns rather than applying filters at the full table level. If the goal is to preserve existing filter context while refining it, KEEPFILTERS should be used on those column-level conditions.

For measures, it’s also important to define the correct grain of evaluation. This is where VALUES() becomes important- it limits the evaluation context to a single column so the measure is computed at a controlled level of detail rather than across the entire table.

That column should ideally represent the lowest appropriate grain with the least necessary cardinality for the calculation. In other words, it should be a stable grouping column that matches how the measure is intended to behave.

Count_Items_To_Process =
VAR LimitDate = [CurrentDateMinus1]
RETURN
    CALCULATE (
        DISTINCTCOUNT ( Activity_Log[ItemID] ),
        KEEPFILTERS ( Dim_Items[Status]
            IN { "Approved", "Started" } && Dim_Items[GoLiveDate] < LimitDate ),
        FILTER (
            VALUES ( Dim_Items[<AppropriateGrainColumn>] ),
            [% Progress Ratio] > 0.9
        )
    )