Forum Discussion
Filtering with fields that have multiple selections - What are people doing?
- Anonymous1 year ago
Hi AmberJane ,
It is caused by the filter context, you can create a measure as below to get the count of incidents which fulfill the requirement:
# of Incidents = VAR _selcausedby = SELECTEDVALUE ( 'Caused by'[Caused by] ) RETURN CALCULATE ( COUNT ( 'Table'[ID] ), FILTER ( 'Table', SEARCH ( _selcausedby, 'Table'[Caused by], 1, 0 ) > 0 ) )Best Regards
Dear AmberJane ,
The key difference between unpivoting the data and splitting by delimiter lies in how the data is structured and how the relationships between the data are managed:
Splitting by Delimiter:
When you split the client field by a delimiter (e.g., a comma), you essentially create multiple rows for a single ticket, each containing one of the clients. But the ticket information is duplicated across these rows, meaning the rest of the ticket data (like ticket ID, issue description, etc.) is repeated for each client. This creates a lot of redundancy in your dataset, which can lead to bloated data and potential performance issues.
For example, if one ticket impacts three clients (Apple, X, Uber), splitting the column by delimiter results in three rows for that single ticket, which includes redundant information in every row (ticket ID, issue description, etc.). Filtering becomes messy because you’re working with redundant rows, and you might run into problems like aggregating data (such as summing the number of tickets) since you have duplicates.
Unpivoting:
When you unpivot the data, you're reshaping it in a more structured way, without duplicating any ticket data unnecessarily. Instead of splitting and repeating ticket information for every client, you're creating a new row only for the client, keeping the ticket-level information intact.
For example, if a ticket impacts three clients (Apple, X, Uber), unpivoting would give you three separate rows:
- One row for Apple
- One row for X
- One row for Uber
Each of these rows would still reference the same ticket, but you wouldn’t have the full redundancy of the ticket information being repeated three times. The unpivoted structure is cleaner and doesn’t lead to excessive duplication, making it much easier to filter and aggregate data later on.
Please mark this post as solution if it helps you. Appreciate Kudos.
This sounds like exactly what I need but I am playing with unpivot and getting nothing. Here is what my dataset looks like:
With my mock data I am using caused by and not client. Sorry for the confusion but the same issue applies.
- Anonymous1 year agoNot applicable
Hi AmberJane ,
I created a sample pbix file(see the attachment), please check if that is what you want.
Best Regards
- AmberJane1 year agoHelper III
This worked with the table I have but its not working with other reports. For example I have a card that just shows the # of incidents and I cannot add that flag to the filter for the card.
- Anonymous1 year agoNot applicable
Hi AmberJane ,
It is caused by the filter context, you can create a measure as below to get the count of incidents which fulfill the requirement:
# of Incidents = VAR _selcausedby = SELECTEDVALUE ( 'Caused by'[Caused by] ) RETURN CALCULATE ( COUNT ( 'Table'[ID] ), FILTER ( 'Table', SEARCH ( _selcausedby, 'Table'[Caused by], 1, 0 ) > 0 ) )Best Regards