July 2, 2026

Autodesk Forma to Power BI: Custom BIM Dashboards for ACC Model Data

A practical look at connecting Autodesk Forma and former ACC project data to custom Power BI BIM dashboards with large-model support, viewer extensions, issues, assets, and model properties.

Frame Team

Autodesk Forma to Power BI: Custom BIM Dashboards for ACC Model Data

I have been seeing the same naming problem show up in BIM reporting conversations.

Some teams still say Autodesk Construction Cloud. Autodesk now says ACC is part of Autodesk Forma. A few help pages still use older names. Power BI has connectors and templates that reference both construction data and Forma. The project team usually does not care about the branding history. They care about getting model, issue, asset, and coordination data into a dashboard they can trust.

That is the workflow this post is about.

What Changed With ACC And Forma

Autodesk announced in 2026 that Autodesk Construction Cloud is now part of Autodesk Forma. Autodesk’s construction site also notes that ACC product names have been updated, while some resources may still reflect previous branding.

For reporting work, the important takeaway is practical:

your project data may still live in familiar ACC-style projects and products
Autodesk is increasingly presenting those workflows under Forma
Power BI documentation may mention Autodesk Forma, Autodesk Construction Cloud, Data Connector, Data Exchange, or Power BI templates depending on the data path

This creates a real search problem. A BIM manager might search “ACC Power BI.” A project controls lead might search “Autodesk Forma dashboard.” A data analyst might search “Autodesk Construction Cloud Power Query connector.”

They are often trying to do the same thing.

The Native Autodesk Paths

There are a few official ways to think about Autodesk data in Power BI.

Autodesk’s Construction Data Connector is positioned for syncing construction data to business intelligence tools, including scheduled exports, Power BI Connector sync, and API access.

Microsoft documents an Autodesk Construction Cloud Power Query connector that works with Autodesk-provided Power BI templates from the Data Connector template gallery.

Autodesk help also documents how to add the Autodesk Forma connector in Power BI. Autodesk Learning has a tutorial on connecting Data Exchange and Forma asset information inside Power BI.

These are useful paths, especially when the source data is construction management data, asset status, or Data Exchange content.

The question for BIM teams is slightly different: what should happen when the report needs the model itself?

That question connects directly to the Autodesk Viewer in Power BI workflow: project data explains the work, while the viewer lets reviewers verify the model objects behind the report.

The BIM Dashboard Problem

A model-aware dashboard needs more than a project table.

For a coordination or model health report, the team usually wants:

model elements grouped by category, family, type, level, and source model
parameter completeness across objects
quantities by package or location
issue context from Forma or ACC
clash or coordination status when Navisworks is part of the workflow
version changes between model publishes
a viewer surface that lets reviewers inspect selected objects

This is where the dashboard starts to become a BIM workflow instead of a business intelligence export.

The artifact the team wants on Monday morning is usually a Power BI page that can answer a coordination question:

“Which model version produced this quantity?”
“Which assets are missing maintainable fields?”
“Which issues are still open by trade and level?”
“Which objects changed since the last publish?”
“Can we click the chart and see those objects in 3D?”

Those questions need project data and model data to meet in the same place.

A Practical Forma To Power BI Workflow

The workflow I would start with has four parts.

1. Decide Which Data Belongs In The Report

Forma and ACC can hold a lot of project context. Pulling everything into Power BI makes the report harder to maintain.

For a first dashboard, choose one review habit:

model health review
quantity takeoff review
issue performance review
asset readiness review
coordination or clash review

Then define the tables needed for that habit.

For example, an issue performance dashboard may need issue status, assignee, type, location, due date, linked model object, and project. A model health dashboard may need elements, properties, levels, categories, parameter values, and model versions.

2. Keep Model Identifiers Stable

The report needs stable keys between the viewer, the model property tables, and the Power BI visuals.

This sounds like an implementation detail, but it affects the review. If a chart segment cannot reliably isolate the related objects in the viewer, the team will stop trusting the dashboard.

Frame keeps this explicit by preparing model object tables and property tables with identifiers that the viewer workflow can use.

3. Separate Raw Project Data From Review Tables

Raw exports are rarely the final reporting shape.

A clean Power BI model usually needs prepared review tables:

Elements
Properties
ModelVersions
Issues
ClashReports
Markups

The names matter less than the habit. The report should be built on tables that match the review, not just on whatever the connector returned first.

This is one of the places where Frame’s dataset shape is intentionally simple. The report starts from Frame-created queries like Assets and Properties. Teams can duplicate those queries to create their own reporting tables without starting from a raw model export every time. It is a small modeling habit, but it keeps the report clearer and reduces the work Power BI has to do when the Forma or ACC model is large.

4. Put A Viewer Beside The Metrics

The viewer is what keeps the report from becoming detached from the project.

If the dashboard says Level 04 has missing classification values, the BIM lead should be able to isolate those objects. If an issue group looks stale, the coordinator should be able to inspect the related model context before the meeting. If a quantity changed, the team should be able to see the affected objects rather than argue from a number alone.

For Frame, this is also where the custom viewer becomes important. The viewer is built on Autodesk Viewer technology, then extended for Power BI review work: colors, markers, saved views, isolated element sets, saved color states, and selection sync between the model and the outside visuals.

That means the dashboard can behave like a coordination surface, not only a report page. A chart can color the model. A model selection can filter the charts. A saved view can preserve the exact camera, isolated objects, and color logic the team used in the previous meeting.

Big Models Are The Stress Test

The hardest Forma-to-Power-BI workflows are usually not hard because the first chart is complicated. They are hard because the model is real.

Large Revit models, IFC exports, federated ACC projects, and Navisworks coordination files push the limits of connector-first reporting. In our own comparisons with Autodesk Data Exchange-style workflows, this has been one of the places where Frame’s architecture matters most. Some workflows can describe the model, but struggle when the model gets large enough that the dashboard, viewer, and report refresh all need to cooperate.

Frame’s reporting pipeline is designed around that larger case:

model processing happens before the Power BI template opens
datasets are shaped into report-friendly tables
core Assets and Properties queries give report authors a clearer starting point than raw model exports
version comparison and model diff work can be materialized server-side
viewer selections use stable object identifiers
saved colors, saved views, and isolated element sets are stored as reusable viewer state
the Power BI viewer is built for interaction with both the model and external report visuals

We should write a full post about this architecture because it is one of the main reasons Frame exists. For this workflow, the important point is simpler: connecting Forma or ACC to Power BI is only useful if the path still works when the project model is big.

Where Frame Fits

Frame sits in the model-to-dashboard part of this workflow.

You can connect models from Autodesk Construction Cloud/Forma-backed projects or upload local Revit, IFC, and Navisworks files. Frame processes the model, extracts the object tree and properties, prepares analytics artifacts, and gives the team Power BI templates that already understand BIM data.

The same pipeline supports the viewer state used in the report: selected objects, color rules, saved views, isolated elements, and model-to-visual interaction. The dashboard is not just reading a table from Forma or ACC. It is using the processed model as an interactive reporting layer.

For Forma/ACC workflows, the goal is not to replace Autodesk’s data connectors. Those are useful for construction management and platform data. The goal is to make the BIM reporting layer easier to stand up when the dashboard needs model objects, model properties, viewer context, and repeatable Power BI templates.

This becomes especially useful for:

ACC or Forma model dashboards
model health dashboards
asset and equipment reviews
Revit or IFC quantity takeoffs
Navisworks clash and coordination reports
version comparison dashboards
executive Power BI pages that still need model traceability

A Good First Dashboard

If you are building a Forma-to-Power-BI workflow, I would start with one dashboard page:

project and model selectors
issue or object status cards
counts by category, level, status, or trade
a table of objects or issues that need review
selected item details
a viewer panel for model context

Then use it in a real review meeting.

The meeting will show where the data model is weak. Maybe the location field is too inconsistent. Maybe issue types are not used the same way across projects. Maybe the model has the right objects but the parameters are not ready for reporting. Those findings are not failures. They are the actual work of making construction data useful.

The Naming Will Keep Moving

I think this area is still early. Autodesk Forma is becoming the broader industry cloud name, ACC language will remain in many teams for a while, and Power BI workflows will keep using a mix of connector, template, API, and model processing paths.

The practical habit is to write down the data path for each report:

What source system did the data come from?
Which connector, API, or model processing step shaped it?
Which Power BI table does the team review?
Which model object or issue can the reviewer click to verify the result?

That small note makes the dashboard easier to maintain when names, connectors, and project workflows keep changing.