Understanding Report

Hey powerbiexpert22​ 
my suggestion would be to save the report as PBIR and let an LLM analyze the project structure for you.
Then use the LLM as a kind of assistant while you navigate the report: ask it to explain the data model, measures, relationships, pages, visuals, filters, bookmarks, dependencies, and anything that looks unusual or important.
Tools like Codex or Claude Code can be useful for this because they can inspect the whole PBIR project, so you can ask very specific questions while you explore it.
I think this is one of the fastest ways to understand an undocumented report without relying only on manual inspection, especially if you want to avoid missing small details.

Hi powerbiexpert22​ 

In the past, what I would do is go to a visual and try to understand how the numbers were calculated. That meant tracing the columns used, the measure logic, the filters applied, and the relationships. With AI now, you should be able to get a good heads-up on all of that.

Hi powerbiexpert22​,

Good question to ask before trying it. When you save as a Power BI project, most of what the AI reads is metadata, like table and column names, DAX measures, Power Query steps and visual settings. For DirectQuery there's no data stored at all. For Import mode, the actual data sits in a cache.abf file inside the .pbi folder of the semantic model. Exclude that folder or work from a copy without it, and the AI never sees your rows.

That said, metadata can still be sensitive. Server and database names show up in the M queries, and filters in the report files can contain real values like customer or product names. So I'd skim a few files first to see what's in there.

The bigger question is which tool you use. Enterprise versions of these tools usually don't train on your data, but consumer accounts can have different terms. Check with your IT or security team which AI tools are approved, and use the company licensed one rather than a personal account. If nothing is approved yet, Tabular Editor and DAX Query View get you a long way without anything leaving your machine.

Hi powerbiexpert22​,

Yes - I normally reverse-engineer an undocumented Power BI report from the report layer downward rather than trying to understand the entire PBIX at once.

A practical sequence is:

1. Start with one important page and identify the main visuals, slicers, page filters, drill-through, bookmarks, and interactions.

2. Open Model view  and trace the tables and relationships behind that page. This usually tells you very quickly which fact tables, dimensions, and filter paths matter.

3. Use Model explorer to inspect the measures, relationships, roles, calculation groups, and other model objects without manually hunting through every table.

4. For an important visual, run Performance Analyzer, refresh that visual, and inspect its DAX query. You can also send the visual query directly into DAX Query View.

5. In DAX Query View, the “Define all measures in the model” quick query is especially useful because it gives you a searchable view of the measure definitions.

I would not try to document everything immediately. Pick one business question or one critical page, trace:

visual -> measure -> related tables -> filters -> source

and document that path. Once you understand two or three important flows, the rest of the report usually becomes much easier to map.

If the PBIX uses Power Query heavily, I would only trace the M/query steps for the tables involved in those important flows rather than reading every query first.

AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.

In the experience, I follow the next steps, Power Query (Sources) -> Data model (RLS, OLS) ->  Pages  -> Visual -> Measures , in a few hours you get a minimal knowlegde!  

Tools as killer measure, tabular editor.. are still usefull.