Power BI ModelSweep: Clean Up Your Power BI Model Without the Toolchain
Power BI ModelSweep is an editable Power BI project that brings model health, field usage, dependencies, best-practice findings and cleanup outputs into one audit workspace. It helps you answer a practical question: what can we improve in this model, and what evidence should we check before changing it?
This guide explains how to set up your first scan, interpret the main pages and move from a finding to a tested change. The screenshots show the toolkit interface; they are not a measured customer before-and-after case study.
Who is ModelSweep for?
Power BI developers reviewing a model before a release, refactor or handover.
Analysts inheriting a report and trying to understand its fields, calculations and dependencies.
Consultants who need a repeatable audit process and model documentation.
Teams maintaining several reports connected to the same semantic model.
A typical starting point is an inherited sales report containing old measures, hidden columns and several connected reports. ModelSweep helps you assemble a review list; the model owner still decides what has business value.
Why choose an audit project instead of another standalone application?
The core PBIP workflow runs inside Power BI Desktop. ModelSweep is not a separate executable to install, and the local file-based audit does not itself require a new tenant role or administrator elevation. You need Power BI Desktop already available and permission to read the project files.
The advantage is consolidation: usage, model metadata, report structure, diagnostics and reviewable outputs sit together in an editable project. You can move from a headline finding to supporting detail without maintaining a separate spreadsheet for every audit question.
This is not a claim that every workflow is installation-free. PBIX analysis uses Tabular Editor exports; optional storage metrics come from a DAX Studio VPAX export. Running generated code may also require an appropriate editor. Your organisation’s file-access, software and data-handling policies still apply.
Before you start: choose the right input
PBIP project: the most direct route. Keep the .pbip file and its associated Report and SemanticModel folders together; the entry file alone is not the full project.
PBIX file: follow the bundled Instructions page to generate the required Tabular Editor 2 exports. Also run the supplied Export ModelMetadata script and place ModelMetadata.txt alongside the PBIX.
Additional reports: include the reports connected to the same model that you want covered. A local scan cannot discover every external consumer automatically.
Optional VPAX: add storage metrics if you want to prioritise candidates by size, not just by object count.
Microsoft documents PBIP as a text-based project format. If you need to save a PBIX as a project, follow the current Power BI Desktop projects guidance. The feature is currently documented as preview, so check compatibility and your organisation’s policy.
Setup: your first scan, step by step
Make a backup of the target report or project. Keep ModelSweep’s own project separate from the project you are analysing.
Open the supplied Power BI Cleanup tool.pbip file in Power BI Desktop. The package filename can still use the earlier name even though the product is branded Power BI ModelSweep.
Go to Transform data → Edit parameters. Set “1: file path & filename” to the full path of the target .pbip or .pbix, including its filename and extension. Replace the supplied sample path before your first refresh.
Set “2: Additional report paths (semicolon separated)” when other reports use the same model. Separate their paths with semicolons; leave the single dot when there are none.
Choose the analysis depth. Enable “do you want to load the Measure dependency path?” for the dependency graph and “do you want to load the deep report analysis?” for detailed report references. On large reports, you can first scan with these disabled, then enable them before making deletion decisions.
Optionally set “4: VertiPaq .vpax file path”. Use a matching export from the target model, or leave a dot for auto-discovery. Check the resolved filename on Start so that you do not interpret an unrelated export.
Refresh ModelSweep, then open Start. Check what loaded, what is missing and which analysis options ran before reviewing the findings.
Read the scan coverage before reading the score
A successful refresh does not automatically mean a complete audit. Missing PBIX exports, an unsupported report structure or disabled deep analysis can leave particular modules empty. Start and the Scan Coverage information on Model Health explain which evidence is available.
Treat “no findings in this module” differently from “this module did not load”. For example, missing ModelMetadata.txt can leave PBIX data types, relationship details, descriptions and sources unavailable, so dependent checks are skipped. Resolve important gaps before calling a model clean.
What each audit page tells you
Model Health: where should I begin?
Review the object counts, unused-field and unused-measure candidates, findings by severity and scan coverage together. The health score is a summary of the toolkit’s checks, not a Microsoft certification or proof that reports are correct. Start with consequential findings and incomplete coverage rather than trying to improve the score in isolation.
Usage Map and Dependency Explorer: what depends on this object?
Usage Map separates field references across DAX, Power Query, relationships and visuals. Measures are also classified by uses such as other measures, filters and formatting. Dependency Explorer lets you select a measure, inspect its expression and follow upstream and downstream dependencies.
This matters because “not visible in a chart” is not the same as “unused”. A calculation can support another measure, a dynamic title, conditional formatting, a tooltip or security logic. Review the full dependency path and every report included in scope before removing it.
Best Practices: what needs investigation?
Findings include severity, an explanation and suggested corrective action. The checks cover areas such as model design, DAX, naming, documentation, sources, security and report accessibility. Use them as a review queue: a pattern flagged by a rule may be intentional, and an accepted exception should be documented.
Report Inventory: what is inside the report?
Inspect pages, visuals, custom visuals and bookmarks, including indicators such as off-canvas visuals and missing alt text. An apparently orphaned or hidden page still needs review: it may serve as a tooltip, drillthrough destination or navigation target. Detailed coverage depends on the available report definition.
Relationships & Sources: how is the model connected?
Review relationship cardinality, direction and active status alongside the detected source connectors. Flags for local paths, native queries, possible credentials in M or query-folding risks help identify items for investigation; they do not by themselves prove a performance or security defect.
Security & Model Logic: what changes the result?
Where metadata is available, inspect role definitions, row-level and object-level security, calculation groups and field parameters. Check these before simplifying a model. A relationship flagged in a model with security roles warrants role-based testing; the flag alone does not establish that data is exposed.
Change Tracking and Scan Diagnostics: what changed, and what loaded?
Change Tracking uses available file modification timestamps and age buckets to highlight potentially stale objects. It is not a complete version history: copied files can change timestamps, and a PBIX offers less granular information than project files.
Scan Diagnostics helps investigate empty pages and errors using query status, row counts and timings. Those timings describe analysis queries and can include upstream work. They are not a benchmark of your report visuals, and summing them is not a reliable estimate of total Desktop refresh time.
Three examples: turning findings into decisions
The following examples are illustrative workflows, not measured results from the screenshots.
Example 1: an apparently unused customer column
Suppose a legacy customer attribute is flagged as a deletion candidate. Check its references in Power Query, DAX, relationships, sorting, security and report definitions. Include other reports using the model and ask the owner about consumers outside the scan. If the checks support removal, test it on a copy and compare report behaviour before approving the change.
Example 2: a measure that never appears on a visual
A base measure such as Revenue may only be referenced by Margin % and Revenue YTD. Removing it because it is absent from a visual would break those calculations. Follow the downstream path in Dependency Explorer. Keeping and documenting the base measure can be the correct outcome of the audit.
Example 3: a large cleanup candidate
With a current VPAX export, compare a candidate’s dictionary and data size with other candidates. A large unreferenced text column may deserve attention before several small fields. Reclaimable MB is a prioritisation estimate, not a guaranteed reduction in the saved PBIX or a promise of faster reports.
For the optional export workflow, see DAX Studio’s Model Metrics documentation. Export metrics for the relevant model and use a fresh export after any change you want to measure.
From finding to fix: a controlled cleanup workflow
Cleanup Scripts provides generated Tabular Editor C#, an unused-object list, Power Query snippets, a model dictionary and measure-recreation output. These are reviewable artefacts; refreshing the audit is not the same as executing the generated changes.
Record the baseline: target files, included reports, scan options, coverage and findings. Save the original project and any matching VPAX export.
Create a shortlist. For each candidate, record the evidence, business owner and decision: keep, document, investigate or remove.
Inspect the relevant generated output. To copy a complete value from a table cell, use right-click → Copy → Value. Do not execute an entire generated script without reviewing its targets.
Apply a small, approved batch to a test copy using the appropriate editor. Keep the target model distinct from the ModelSweep audit project.
Refresh the target model and test totals, key measures, slicers, filters, drillthrough, bookmarks, tooltips, formatting and relevant security roles. Test connected reports too.
Save the changes, obtain a new VPAX export if measuring storage, and refresh ModelSweep against the updated files with comparable scan settings.
Compare the evidence and document the outcome. Promote the tested version only after the model owner’s normal review and release process.
Before and after: what should actually improve?
Before: a field looks unused. After: its references, scan coverage and known consumers have been reviewed, with an explicit keep-or-remove decision.
Before: model knowledge lives in scattered notes. After: the team has a review list, dependency evidence and a model dictionary for handover.
Before: cleanup benefits are assumed. After: the team compares actual storage exports and separately tests refresh or report performance under comparable conditions.
No fixed percentage saving is claimed here. Removing genuinely unnecessary objects may simplify maintenance, but performance and storage outcomes depend on the specific model. A valid audit may also conclude that an object should stay.
Common questions and troubleshooting
Why do I see a file-not-found error?
Check that parameter 1 no longer points to the supplied sample file. Enter the complete filename and extension, confirm the associated project folders exist and ensure you have read access. A folder path on its own is not the required input.
Why are storage figures missing?
Check the VPAX filename resolved on Start. Without a readable matching export, storage tables can remain empty while the rest of the audit still runs. Missing storage data is not a zero-size model.
Can I delete everything marked unused?
No. Candidates depend on the scanned files and enabled analyses. Unscanned reports, external consumers, ambiguous field names and dynamic references can limit the evidence. Complete the dependency review and test on a copy.
Does this replace every Power BI utility?
No. It consolidates a broad local audit workflow. Specialist query profiling, optional metadata exports, change execution and deployment may still require other tools and existing permissions.
Built with Codex, grounded in the project
ModelSweep’s development and supporting materials used a Codex-assisted workflow. The accompanying sales assets used Creative Production, Presentations, PDF and Computer Use skills for visual production, document preparation and interface verification. These describe the creation process, not prerequisites for using ModelSweep.
The toolkit builds on Remco Verkoeijen’s Power BI Clean Tool, with additional audit pages, metadata analysis, diagnostics and generated outputs documented in the bundled README. Use the README and Instructions page for the requirements of your package version.
Your first practical next step
Choose one report you know well. Run a scan, confirm coverage, investigate one unused candidate and one best-practice finding, then document the decision. This gives you a repeatable starting point for broader model reviews without treating a score or a generated script as a substitute for judgement.
Comments