Forum Discussion
Custom Visual Highlighting/Selection stops working
Hi v-sshirivolu ,
I have issued the ticket - When I will receive any solution, certainly I will share it here 🙂
Community SupportHi Q-Click ,
The behavior you’re observing is expected due to how Power BI handles highlights and row identities in Table/Matrix visuals. Highlights (categorical.values[x].highlights) are only sent reliably for small tables or when a single selection exists. For larger tables, multiple columns, or rows containing nulls, Power BI may omit highlights or send placeholder identities (0,1,2…), which cannot be used to detect actual row selection.
To address this issue, add a unique key column (e.g., RowID) as the first categorical column in your table or matrix and rely on it to detect row selection instead of highlights, so selections remain reliable even if identities are placeholders or highlights are missing. For interactive visuals, you can optionally use ISelectionManager to register selections more consistently. Keep your fallback logic for single-row tables to default to row 0. This approach ensures your visual reliably detects selections even with many columns, added categorical fields, null values, or larger datasets, eliminating dependence on inconsistent highlights and placeholder identities and maintaining full commenting functionality.
Community SupportHi Q-Click ,
I hope the information provided above assists you in resolving the issue. If you have any additional questions or concerns, please do not hesitate to contact us. We are here to support you and will be happy to help with any further assistance you may need.
Hi,
v-sshirivolu Thanks for your response!
I have a follow-up question regarding the “unique RowID column” solution.
Would adding a RowID column truly solve the issue, or is it only a partial workaround?More specifically:
Will this approach still remain reliable if the table/matrix becomes very wide or contains many categorical columns?
The selection/highlighting interruption that I’m seeing appears only when the dataset becomes large enough or when additional columns are introduced.How exactly should a custom visual consume this RowID column?
Since the recommended approach is to avoid relying on highlights[], and the Selection Manager is only suggested as an optional alternative, I’m trying to understand how adding a RowID changes the behavior of how Power BI sends filter/selection context to custom visuals.Does Power BI guarantee that a RowID used as a single unique category will always produce stable identity or filtering context for the custom visual, regardless of dataset size or number of columns?
I ask this because previously the selection context simply stopped being passed once the table became too large, even though no RowID was involved.
I would really appreciate clarification on how adding this RowID is supposed to help technically, and whether it avoids the limitations that cause Power BI to drop highlight arrays or identity information when the underlying table becomes large.
Thanks again!
- v-sshirivolu
Hi Q-Click ,
The RowID approach isn't a full fix for Power BI's data reduction limits, but it's the most reliable way to keep selection and highlighting working when your dataset becomes large or has many categorical columns. The issue occurs because Power BI drops or compresses identity and highlight data once the model gets too big. When identities are built from multiple columns, they’re the first to be reduced, which is why selection suddenly stops working.
Using a single unique RowID avoids this because Power BI only needs to send one simple categorical value per row, and that identity remains stable even as the dataset grows. In your custom visual, RowID should be used as the main category for selection so you get one consistent identity per row. Power BI handles these single column identities far more reliably than multi column ones. While it doesn’t remove the underlying Power BI limits, it prevents the selection/highlighting drop off you’re encountering.
Based on your description, it appears that there is no complete or guaranteed fix for this scenario in the current Power BI custom visuals framework.
Even with a surrogate RowID, the main limitation still remains:
once the dataset reaches certain size or complexity,
Power BI will still reduce or drop identity/highlight data,
and the custom visual will no longer reliably receive the full selection context.
Since the core purpose of my visual is to read all column values from the currently selected row, this limitation means that even with a RowID in place, at some point the visual will again stop receiving enough information to reconstruct the full row. The RowID helps reduce the likelihood, but it does not eliminate the underlying behaviour.
From your explanation, it sounds like:
Power BI does not currently provide a fully reliable mechanism for passing stable identity/highlight data for large tables/matrices,
multi-column identities will always break first,
and even single-column identities (RowID) are not guaranteed once the data reduction rules trigger.
If this limitation is expected by design and not on the roadmap to be improved, then custom visuals that depend on row-level values from user selections will always hit this boundary sooner or later — regardless of the implementation.
Please let me know if this interpretation is correct, but based on your description it seems that the issue cannot be fully avoided with the current SDK capabilities.
EDIT:
Additionally when I tried various approaches it is still not a viable solution.
Selection manager as optional solution won't work becasue my visual is based on selection of the other visuals. In table or matrix You are highlighting something and my visual knows at which row You are at and what is specifically in this row. So without proper highlights it does not work, even if my visual has only one category chosen in dataset, and table which I am using has 5 categories and few measures. It is not like 10,000 row length dataset