Forum Discussion
Advocate ICalculation group at page-level not applied for some random users
cengizhanarslan thank you for the deep and thoughtful reply. Reasons 1 & 2 are not applicable, these have been checked and things are as they should with no mistypes or wrong emails/UPNs.
As i see it, even if there was some such error, the calc group CALCULATE modifier would not find a match for the "dimUsers[upn] = _upn" part, and it would return BLANK - instead, it returns a value as if ALL users were in the filter context.
Reason 3 is also ruled out, bookmarks and reset-filters have been considered.
The only solution so far was to apply the calc group on the visual-level (on all required visuals) instead of page-level.
Super UserThis issue typically stems from how Power BI handles filters and security contexts differently at the page level versus the visual level. If your dimUsers table does not contain a specific user's UPN, or if there is a mismatch, the CALCULATE filter results in an empty set or a cross-join, which can cause the measure to show "All" data depending on your model relationships.
Here are the most likely reasons this is happening to a small subset of users:
1. Case Sensitivity & Character Mismatch
Power BI and DAX are generally case-insensitive, but the underlying data source or specific collation settings can sometimes cause issues.
The Issue: A user's email in Azure AD might be [email protected], but your dimUsers[upn] table contains [email protected].
The Fix: Wrap both sides in LOWER() within your calculation item: VAR _upn = LOWER(USERPRINCIPALNAME()) RETURN CALCULATE(SELECTEDMEASURE(), LOWER(dimUsers[upn]) = _upn)
2. User Principal Name (UPN) vs. Email Address
For most users, the UPN and Email are identical, but for some (especially those with alias changes or legacy accounts), they differ.
The Issue: USERPRINCIPALNAME() returns the sign-in identity. If these 10 users have a UPN that doesn't match the email stored in your upn column, the filter will fail.
Verification: Add a card visual to a hidden page that simply displays the measure UPN_Check = USERPRINCIPALNAME(). Ask an affected user to send a screenshot of that value to compare against your table.
3. Page-Level Filter "Ghosting"
Page-level filters are applied as an outer context. If a user has "Persistent Filters" enabled in the Power BI Service, they might have accidentally cleared or "searched" in the filter pane, causing the page-level filter to become inactive or invalid for their specific session.
The Fix: Have the affected users click the "Reset to default" button at the top of the Power BI service bar.
Advocate Icengizhanarslan thank you for the deep and thoughtful reply. Reasons 1 & 2 are not applicable, these have been checked and things are as they should with no mistypes or wrong emails/UPNs.
As i see it, even if there was some such error, the calc group CALCULATE modifier would not find a match for the "dimUsers[upn] = _upn" part, and it would return BLANK - instead, it returns a value as if ALL users were in the filter context.
Reason 3 is also ruled out, bookmarks and reset-filters have been considered.
The only solution so far was to apply the calc group on the visual-level (on all required visuals) instead of page-level.
v-echaithraCommunity Support
Hi nyarlathotep ,
Thank you for confirming that the issue has been resolved. If you encounter any new issues, feel free to start a new thread in the community. We're always here to assist you!
Best Regards.