Is "Drill Across" Functionality (as in MicroStrategy) Possible in Power BI?

[Sidhant]

Hi everyone,
I wanted to check the feasibility of a feature I’ve seen in MicroStrategy (MSTR) called "Drill Across" — and whether something similar is possible in Power BI, either natively or through workarounds.

Background:

In Power BI, we’re familiar with drill throughs and hierarchical drilldowns (e.g., drilling down a date hierarchy: Year → Quarter → Month). However, in MicroStrategy, the "Drill Across" feature allows more flexibility — enabling you to drill not just within a hierarchy, but across unrelated columns or attributes, even if they aren’t part of the same group.

📌 Example (MicroStrategy):

In MSTR, we define a Drill Map by selecting columns from different tables or categories:

• Up / Down: Typically used for hierarchical or related columns (e.g., Category → Sub-Category).

• Across: Allows selection of unrelated columns, enabling users to drill from one data point to another attribute from a different domain (e.g., from "Product" to "Customer Region" or "Order Status"), which wouldn't traditionally fall under the same hierarchy.

This is configured via a "Template" and "Drill Map" setup in MSTR (screenshot not included here). While Power BI doesn't have a concept of Templates in the same way, I’m hoping to understand if a similar "Drill Across" interaction can be replicated.

Drill Map creation in MSTRDrill Across in action

I had couple of questions that I had which were as follows:

Can we implement "Drill Across" functionality in Power BI?
More specifically:

• Is it possible to allow users to drill from one field to another that is unrelated in terms of hierarchy?

• Are there any visual-level or report-level workarounds using bookmarks, buttons, custom drill-through pages, or field parameters to achieve this?

• Has anyone built something similar to a "Drill Map" experience in Power BI?

Any guidance, workarounds or creative solutions would be much appreciated.

Thanks in advance,
Sidhant.

[SantoshPothnak]

Hi All,

We appreciate the thoughtful suggestions from @Ritaf1983, @MFelix, and @v-venuppu which helped clarify challenges around scalability, matrix visuals, and data consistency.

 @Sidhant  is from my team, and we have been exploring these approaches in depth. We understand that Power BI does not have a native Drill Across feature like MicroStrategy, but field parameters combined with drillthrough, personalize visuals, and carefully designed semantic models offer the closest viable options currently.

We are continuing to fine-tune our model and DAX logic to improve accuracy and usability.

Special thanks to @MFelix  for his support on this ..Thanks again.

[v-venuppu]

Hi @Sidhant ,

Could you please let us know if there is any update on the closure of this thread..?

Thank you.

[Sidhant]

Hi @v-venuppu ,
Sorry for the delay in my response, I guess so there are no more concerns from my end.
Once again I would like to thank all the responses that were given for this thread. Thank you @Ritaf1983 , @MFelix and @v-venuppu for your valuable inputs.

Regards,
Sidhant.

[v-venuppu]

Hi @Sidhant ,

Please let us know if you have any further questions, if not please confirm are we good to close this thread..?

Thank you.

[Sidhant · Accepted solution]

Hi @v-venuppu,
Probably there are no more questions but there were certain approaches that I have discussed with @MFelix which me and my team are trying to look into, so maybe by the end of this week if there are no further queries we can close that, will keep you posted.

Regards,
Sidhant. 

[v-venuppu]

Hi @Sidhant ,

Using Personalize visuals mainly on tables/matrices is safe and avoids chart-type issues.Combine Perspectives (to restrict which fields users can add) with Row Level Security (to control data visibility).Provide a default view of visuals --> users can add/remove allowed fields, then save their custom setup via Bookmarks.If needed, users can always revert with Reset to default.

 The only caveat: when a report comment is used, Power BI restores the visual to its original saved state, not the personalized version.So yes, your approach is valid. Just keep in mind the small limitation with comments.

Thank you.

[Sidhant]

Hi @v-venuppu ,
Thanks for sharing your inputs with respect to what precautions need to be taken into considerations.

Regards,
Sidhant.

[v-venuppu]

Hi @Sidhant ,

May I ask if you have resolved this issue? Please let us know if you have any further issues, we are happy to help.

Thank you.

[Sidhant]

Hi @v-venuppu ,
Not yet need to check the points @MFelix  had shared few days back (facing some technical issues) due to which was not able to implement them. Once I have will update on this post if there are any issues for the same.

Regards,
Sidhant. 

[Sidhant]

Hi @v-venuppu , @Ritaf1983 , @MFelix  ,
So we can use Field parameters for all visuals and my team mates have found a workaround the Drill across functionality but there are couple of challenges that we still are facing. I will explain you:

✅Current Implementation Approach:

1. Use of CTE (Common Table Expressions):
   • CTEs are being used in SQL to join columns from multiple tables into a unified structure for analysis.
2. Simulating 'Drill Across' via Slicers:
   • To replicate the multiple 'Drill Across' options available in MSTR (via right-click), they have introduced slicers in Power BI that allow users to select various dimensions.
3. Custom Table for Filtering Logic (Stop Loss Table):
   • A new table called ‘Stop Loss’ has been created with values: Greater, Lesser, and All.
     • If Lesser is selected → only values ≤ 0 from the stop loss column are shown.
     • If Greater is selected → only values ≥ 0 are shown.
     • If All is selected (default) → no filtering is applied.
   • This logic is implemented via DAX based on slicer selection.
4. Use of Field Parameters and DAX:
   • Based on slicer selections and user inputs, DAX expressions are used to dynamically filter and calculate the relevant data.

---

❗Current Challenges:

1. Scalability of CTE-based Approach:
   • The original report in MSTR has 10-15 Drill Across options, each with 4-5 sub-options (columns).
   • Currently, they have implemented 4-6 options in Power BI.
   • Challenge: For every new column addition, the CTE SQL query needs to be restructured from scratch. Even for a single column, the entire table must be brought in and re-joined — making it time-consuming and less scalable.
2. Data Discrepancies:
   • Although the DAX logic appears correct, the output data is sometimes inaccurate or inconsistent with expectations.
   • The root cause is still being investigated, but it introduces reliability concerns.

---

📌Comparison with MicroStrategy (MSTR):

• In MSTR, the 'Drill Across' setup is largely a one-time configuration:
  • Create a Drill Map template, add all required columns once.
  • Reuse the same template across multiple reports using the Drill Map Editor.
• In contrast, Power BI requires:
  • Per-report setup of CTE queries, slicers, supporting tables, and measures.

So in this case how can we proceed and resolve some of the discrepencies with respect to the data, if you have any valuable inputs or ways to proceed please do let me know.

Regards,
Sidhant.

[MFelix]

Hi @Sidhant ,

A couple of questions:

• You are using CTE to simulate the drill map template for the columns you need?
• Based on the description (Setup of CTE Queries, slicers, etc...) it seems like you are doing one semantic model for each report you are doing is that correct?

Not sure what is the answered for the previous questions but depending on the result you need I would try to do the following:

• Create a single model with my tables, measures and field parameters this would allow the reusage
• If you don't want to have all the columns available on the field parameters you can add additional columns to the field parameters table that will allow you to for example tell for wich reports they are available and then you can use that as a filter on the report reducinding the options available in each of the reports
• You can also have a dynamica field paramater table using a SQL Table, CSV File or excel that you can adjust at any time adding or reducing rows for each of the options. This will update the Field Parameters automatically on refresh without the need for you to redo any DAX or Power Query update.

[Sidhant]

Hi @MFelix,
I will share our approach with the respective screenshots what we have done so far so that you also have a better understanding,

This was the initial semantic model that was created using SQL/CTC

We have broken the semantic model into 2 parts:

1. Base Model : Known as Model-1
2. Comparison Model: Model-2

In patient population we select the respective option and then in Base model and Comparison Model slicer we get the values associated with the respective value selected in patient_pop-Name slicer and based on that comparison happens.

Additionally we also have created a separate stop_loss table: If we select lesser option -> In the main we have stoploss column show values lesser  (<=) than & equal to  0, similarly for greater: the stoploss column from the main table will be filtered and it will show values greater than and equal (>=) to 0; else by default nothing (all values will show up).

We had created an initial DAX which was being created for the initial semantic model using SQL approach:

Model-1 and Model-2 are being used as slicers (shown in above image)

For the drill across we are trying to achieving shown in the above image. To implement features like Drill across we are using Field Parameters.

Now we are trying to implement the same thing using the data model, we have ditched the SQL approach as its too complex (reasons which I had shared earlier like adding a new column is tedious need to rework on the entire SQL query, perform the required joins from scratch).

Additionally @v-venuppu , @Ritaf1983 you can also share your inputs and if you need any more information do let me know.

Regards,
Sidhant.

[MFelix]

Hi @Sidhant ,

Thank you for the explanation, 

There are a couple of things that I also would need to understand:

• On the last image the table that has several relationships 1-many is the Query 1 that you reference earlier?
• What is the fields parameter that you are using? Or haven't you created them already?

If you want you can reach out trough private message so we can arrange a deeper dive in the model.

[Sidhant]

Hi  @MFelix ,
I will try to answer your queries:-> The data model which has 4 table are 1 single table is a sql table and the one wherein we have 3 are which has relationship are been used as slicers.

-> The other one  which has multiple relationship is a new date model which we are trying to develop currently using all the tables required to build report.

So right now: Data is getting matched for couple of columns but for coulmns we have observed data discrepencies.

Hope I have answered your queries, if there any cross-question or additional queries do let me know. Meanwhile I also try to reach out through private direct message (DM) and we can try to arrange a call wherein we me & team can give you a deep dive about our exploration and the work done.
@v-venuppu , @Ritaf1983  feel free to pitch if you have any inputs for the same

Regards,
Sidhant.

[Sidhant]

Hi @MFelix , @Ritaf1983 
In addition to this I came across 'Personalize visuals' which is not exactly similar to what is needed, but closer to the intended functionality. Wherein once enabled end-user can add new columns change visuals and even their view using bookmarks.
Note: There are certain things that need to be taken care:
 1. Tighter RLS so that user don't get access to all the tables but there is some restrictions using row level or object level security.
2. Creating Perspectives (whereinonly certain set of column access that the end-user can choose from instead of all)

These were the Documemtations that I referred to:
Documentation-1 
Documentation-2 
So I think this may solve the requirement but for compex cases we might still need to figure out the DOM (which is currently in-progress)
Just wanted to give this quick update.

Regards,
Sidhant

[MFelix]

Hi @Sidhant ,

The Customize visuals can also be an option but be aware that this can also give you some questions, based on my experience implementing this features in some reports there were a couple of questions:

• Depending on the model and the calculations people can select the incorrect calculations giving strange results.
  • For example selecting a dimension table that does not filter a spefic fact table
• Since users can also change the visual itself you can have users changing a line chart to a scatter plot and then getting errors because the type of information is not in the correct format
• Based on the changes the users do they may not be looking at the same information has other users making the comparabilaty difficult if they do not know what changes they did
• Usage of comments in changed visuals will revert the visual to the original visualization on the users that are refering to that comment.

[Sidhant]

Hi @MFelix ,
Thanks for highlighting the points (that you experienced), just wanted to clarify some of them:
So for the first three points:
-> Mostly the report wherein we will be making use of Persoanlize visuals it will be on tabular reports (wherein the visuals will be mostly either table or matrix).
-> Then next thing was: Since Personalize visuals option gives end-users to access to all the tables and its respective columns, in order to avoid that we are planning to implement strict Row Level security and using perspectives (which only allow to select from a set of columns and not all).
-> With respect to the view by default there will be a certain view (like visuals with columns that were being used at the time of development: like assume Page-1: We have a table with 4 columns: FirstName, LastName, Sum(Profit) and few cards Card-1: Sum(Quantity), Card-2: Sum(Sales); so later lets say a user wants to add few more columns in the table (like Order Date, OrderID) they simply can add (if they are given in that perspective for that visual) and then just bookmark that specific view and if they want to revert back to the original/default view they simply can reset.

The last point (with respect to commnet) I did not understand.
Hope this answers your queries.

Regards,
Sidhant.

[v-venuppu]

Hi @Sidhant ,

Thank you for reaching out to Microsoft Fabric Community.

Thank you @Ritaf1983 for the prompt response.

I wanted to check if you had the opportunity to review the information provided and resolve the issue..?Please let us know if you need any further assistance.We are happy to help.

Thank you.

[Sidhant]

Hi @v-venuppu ,
I did get some clarity that the Drill-Across is not to be implemented as exact copy what we have in 'MSTR'. So based on that I did try to implement a simple Field Parameter and posted it as comment to see whether it was right or wrong, to which @Ritaf1983 did clarify that was right & did share some resources (videos on Field params).
So I had some follow up questions: Do field parameters only work in case of tabular reports, for the ones with cross which are crosstab like or have some formatting.
Because some of my colleagues did experiment with this and they faced issues with respect to non-tabular reports, to be specific: field parameters work well for tabular reports but the challenge is with matrix reports and pivot style reports.

Regards,
Sidhant.

[MFelix]

Hi @Sidhant 

Field parameters do not play nice with matrix specially when you get the field parameters in both the columns/rows and values, you will get a duplication of the value for each column. If you are using the values to be only columns or rows they will work fine but if you want to use them has values also, for example for measures with groupings you need to be carefull.