Advance your Data & AI career with 50 days of live learning, dataviz contests, hands-on challenges, study groups & certifications and more!
Get registeredGet Fabric Certified for FREE during Fabric Data Days. Don't miss your chance! Request now
Hi there,
We have a custom matrix visual and want to implement drill down on the row hierarchy. I’ve investigated the feasibility of implementing this feature and found a potential issue that could impact other parts of our visual.
When the drill down feature is enabled, Power BI only provides a subset of the data, depending on the hierarchy level. To clarify, drill down functions similarly to a slicer, and data from other visuals is also filtered when using this feature.
I have concerns about maintaining correct formulas that are based on the full dataset, since drill down filters the dataset and we may not have access to all the necessary data for these formulas.
My question: Is it possible to implement drill down without slicing the Power BI data? (We need the full data to keep our custom formulas funtionality)
@dm-p I’d really appreciate your thoughts on this - do you have any suggestions?
Solved! Go to Solution.
Yes, if you enable drilldown capabilities, then Power BI is only going to send the data that the user has requested to view, which may not be all of it, or it could be a specific level only (which could also be an interim level of a multilevel hierarchy if you're not using a matrix data view mapping and the user is drilling rather than expanding).
I can't speak for combining drill capabilities with filtering/slicing, as I personally avoid doing work with slicers; I have been burned too many times by their limitations, and what this allows me to deliver for clients without significant workarounds, realistically. I would assume that, as the selection/drill APIs and the filter APIs have their own invocation methods, they theoretically could coexist.
The reality of whether this could happen *feels* like a significant problem to solve, and I think it would require a lot more time and effort than I can dedicate to a forum post, or my current capacity would allow. Off the top of my head, I might start by ensuring that something in my formula memoizes or will enable me to discover what level or node the formula applies to, and when the data view is (re) processed, this will need to be taken into consideration to ensure that the correct expansion state is applied programmatically if not already there.
Assuming you are using the matrix data view mapping, you could do this part by selection ID and programmatically expanding the nodes you need with ISelectionManager.toggleExpandCollapse(). With a categorical mapping, this might be achievable with the drilldown API, but it's less targeted than you can do for the matrix mapping.
Hopefully some of this may help, but you may get a definitive answer if you speak directly with the support team and provide them with your scenario.
Good luck,
Daniel
Proud to be a Super User!
On how to ask a technical question, if you really want an answer (courtesy of SQLBI)
@dm-p answer is on point as always.
Alternatively, you can disable native drilldown and implement your own custom drilldown logic inside the visual, storing the selected state using host.persistProperties so your formulas still work on the full dataset.
You can also consider the Dynamic Drill Down API to switch between the "full data state" and the drill state when needed.
Thank you, that makes sense. I was thinking about switching between the 'full data state' and the drill state, but I was not sure if I can actually do it. Thanks a lot for the link. It should help me figure out how.
Thank you for reaching out to the Microsoft Fabric Forum Community.
@dm-p Thanks for the inputs.
I hope the information provided by user was helpful. If you still have questions, please don't hesitate to reach out to the community.
Yes, if you enable drilldown capabilities, then Power BI is only going to send the data that the user has requested to view, which may not be all of it, or it could be a specific level only (which could also be an interim level of a multilevel hierarchy if you're not using a matrix data view mapping and the user is drilling rather than expanding).
I can't speak for combining drill capabilities with filtering/slicing, as I personally avoid doing work with slicers; I have been burned too many times by their limitations, and what this allows me to deliver for clients without significant workarounds, realistically. I would assume that, as the selection/drill APIs and the filter APIs have their own invocation methods, they theoretically could coexist.
The reality of whether this could happen *feels* like a significant problem to solve, and I think it would require a lot more time and effort than I can dedicate to a forum post, or my current capacity would allow. Off the top of my head, I might start by ensuring that something in my formula memoizes or will enable me to discover what level or node the formula applies to, and when the data view is (re) processed, this will need to be taken into consideration to ensure that the correct expansion state is applied programmatically if not already there.
Assuming you are using the matrix data view mapping, you could do this part by selection ID and programmatically expanding the nodes you need with ISelectionManager.toggleExpandCollapse(). With a categorical mapping, this might be achievable with the drilldown API, but it's less targeted than you can do for the matrix mapping.
Hopefully some of this may help, but you may get a definitive answer if you speak directly with the support team and provide them with your scenario.
Good luck,
Daniel
Proud to be a Super User!
On how to ask a technical question, if you really want an answer (courtesy of SQLBI)
Thanks a lot! This looks like it could help. I'll try the selection ID and expanding nodes.
Advance your Data & AI career with 50 days of live learning, contests, hands-on challenges, study groups & certifications and more!
Check out the October 2025 Power BI update to learn about new features.
| User | Count |
|---|---|
| 5 | |
| 3 | |
| 1 | |
| 1 | |
| 1 |