Forum Discussion
Measures count not segregating accordingly in visualization
- 1 year ago
Hi enricm1982 ,
Thanks for reaching out to Microsoft Fabric Community.
I tried to reproduce the issue based on the details you shared with some sample data. Here is a summary of my repro setup:
-
A single Date table marked as the date table.
-
Tickets table with both Created Date and Resolved Date columns.
-
Active relationship between Tickets[Resolved Date] and Date[Date].
-
Inactive relationship between Tickets[Created Date] and Date[Date].
-
Measures using USERELATIONSHIP and TREATAS to switch between these dates.
-
Visuals with YearMonth on X-axis showing counts for Created Issues and Resolved CRs.
To better align the filtering with Resolved Date, the measure for Total Resolved CRs was modified using the USERELATIONSHIP function, which produced the correct filtering behavior in the visual:
Total Resolved CRs = CALCULATE( COUNTROWS('Tickets'), 'Tickets'[Status] IN {"Resolved", "Closed"}, NOT(ISBLANK('Tickets'[Resolved Date])), 'Tickets'[SR - Change Request] = "Yes", USERELATIONSHIP('Date'[Date], 'Tickets'[Resolved Date]) )When I click on a month (e.g April 2024)
If this didn’t fully capture your scenario or meet your expectations, please let us know.
To address the filtering behavior in a single chart, here is an important consideration:
Because Power BI supports only one active relationship between tables at a time, using two date columns related to a single Date table creates filter ambiguity. Measures using USERELATIONSHIP or TREATAS help but don’t fully solve this when visuals filter on both dates.
The best practice is to create two separate Date tables:
-
One linked actively to Created Date.
-
Another linked actively to Resolved Date.
Then use separate visuals for Created and Resolved counts, syncing slicers between these two Date tables to maintain user-friendly filtering.
This approach ensures correct filtering and aggregation without conflicting filter context.
If possible, please share a sample .pbix file (without any sensitive data) that reproduces the issue. That would help us guide you more precisely and confirm if the dual date table approach would resolve it completely in your context.
Hope this helps. Please reach out for further assistance.
If this post helps, then please consider to give a kudos and Accept as the solution to help the other members find it more quickly.Thank you,
Vinay Kumar Eshwara.Attaching .pbix file for reference.
-
Can you please paste the code for your Total count measures? And also a screenshot of the chart highlighting incorrect values?
I'm struggling to visualise this.
Created Issues =
CALCULATE(
[Count Issues RC],
USERELATIONSHIP('Date'[Date], 'Tickets'[Created Date])
)Count Issues RC =
COUNT('Tickets'[Issues Root Cause for Change Success])Total Resolved CRs =
CALCULATE(
COUNTROWS('Tickets'),
'Tickets'[Status] IN {"Resolved", "Closed"},
NOT(ISBLANK('Tickets'[Resolved Date])),
NOT(ISBLANK('Tickets'[SR - Change Request])),
TREATAS(VALUES('Date'[Date]), 'Tickets'[Resolved Date])
)"SR-Change Request" field cannot be shared since it contains sensitive data. It is basically a calculated column that filter the data I need for the CRs.
Screenshot with the problem:
As you can see the count for CRs Resolved is wrong and providing tickets resolved in other months. I added the created date column as reference in the CRs table, you can see is extracting those by created date and not resolved date.
Thanks in advance,
ECM