This usually happens because the drill-through filter is on a column, but your measures are not actually being forced to evaluate at a single ApplicationID (they’re evaluating in a broader context, or through the “wrong” relationship).
The fix is to make every “role/status” measure explicitly anchor itself to the drill-through Application ID and (if needed) activate the correct relationship.
1) First, confirm you have a single ApplicationID in drill-through context
Create a debug measure and put it on the drill-through page:
__AppId In Context =
SELECTEDVALUE ( Applications[ApplicationID], -1 )
If you ever get -1, your drill-through page isn’t filtering to one ApplicationID (or you’re using the wrong field in the Drill-through well).
2) Anchor each role/status measure to that ApplicationID (TREATAS pattern)
Use the ApplicationID from the drill-through table, then force it onto the table your measure reads:
Recruiter Status =
VAR AppId = SELECTEDVALUE ( Applications[ApplicationID] )
RETURN
IF (
ISBLANK ( AppId ),
BLANK(),
CALCULATE (
MAX ( FactWorkflow[RecruiterPhoneScreenStatus] ),
TREATAS ( { AppId }, FactWorkflow[ApplicationID] )
)
)
This avoids “context drifting” when multiple tables/relationships exist.
3) If the value comes through an inactive relationship, activate it explicitly
Example:
Hiring Manager Status =
VAR AppId = SELECTEDVALUE ( Applications[ApplicationID] )
RETURN
CALCULATE (
MAX ( FactWorkflow[HiringManagerReviewStatus] ),
TREATAS ( { AppId }, FactWorkflow[ApplicationID] ),
USERELATIONSHIP ( Applications[ApplicationID], FactWorkflow[ApplicationID] )
)
(Use USERELATIONSHIP only if you truly have an inactive relationship you need.)
4) Don’t use plain MAX/SELECTEDVALUE on a dimension if multiple rows exist
If your “role-based status” is derived from another table (events/notes/etc.), always reduce it with a deterministic rule (latest date, highest step, etc.):
Interview Status =
VAR AppId = SELECTEDVALUE ( Applications[ApplicationID] )
RETURN
CALCULATE (
MAXX (
TOPN (
1,
FILTER ( FactStages, FactStages[ApplicationID] = AppId ),
FactStages[StageDate], DESC
),
FactStages[StageStatus]
)
)
5) Common reason drill-through “works with columns but not measures”
So if you have measures like:
CALCULATE ( ..., REMOVEFILTERS(Applications) )
that will break drill-through unless you re-apply the selected ApplicationID via TREATAS.
_________________________________________________________
If this helped, ✓ Mark as Solution | Kudos appreciated
Connect on LinkedInAI-assisted tools are used solely for wording support. All conclusions are independently reviewed.
