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 share a screenshot of your model?
Unfortunately no, sensitive data.
What are you trying to see? Perhaps I can bring more context.