Skip to main content
The core idea is the single pane of glass: one dashboard to rule them all, one dashboard to find them; one dashboard to bring together FTT/FDD, Graphics, BDH transformations, AssetOps insights, energy data, and custom sensor metrics—and in the module bind them. 🧙 Users gain a unified view of their building operations without having to module-hop.
The guiding question is never “what data can I show?” but “what does this user need to do their job?”
KODE OS already has dedicated modules — FDD, FTT, Graphics, Energy, AssetOps. Building BI exists because answering one operational question often meant hopping between those modules and holding the pieces together in your head. A building intelligence tool consolidates data, metrics, and workflows into one customizable dashboard. There is also a legacy Dashboard module that predates Building BI and is being phased out. If you find yourself in that older module, you are almost certainly in the wrong tool. A strong Building BI dashboard is a focused portal: a few widgets that answer one workflow, not every metric the building can produce.
Completed tutorial dashboard with summary cards, charts, and a device table arranged for a down-devices workflow

Example dashboard built around one operational workflow

​
A portal for a workflow, not a data catalogue

That single pane of glass can pull from across KODE OS — including FDD, FTT, Graphics, AssetOps, energy data, and custom sensor metrics. “Can combine everything” is not “should.” Treat Building BI as a portal tailored to a workflow:
  • A dashboard serves an audience, not a data catalogue. Design for how a specific person works day to day.
  • For executives and analysts, the dashboard may be most of their building-information solution and can justify a comprehensive build-out.
  • For building operators, the bigger risk is overload. Prefer one workflow per dashboard: surface issues, then hand the user off to the right module to act.
As you build, test whether the layout supports the natural progression of that user’s daily tasks. Early on, ask a colleague what the user actually needs.

​
Editorial restraint is the hard part

Nothing stops you from adding another chart. The limiting skill is editorial restraint, not technical capability. The same tension shows up in Top N vs scrolling, drill-through, and styling best practices. One giant dashboard that shows everything to everyone is what Building BI makes possible — and what good practice avoids.
  • Value depends on configuration quality upstream (ontology, point modeling, integrations). A single pane of glass over messy data is still messy.
  • “Tailor to the user” assumes you know the user. When you do not, treat early dashboards as drafts.
  • Some organizations restrict roles so a user only ever sees one building. Do not assume everyone can reach a portfolio-level view. See Portfolio and building scope.

​
Next steps

Building BI overview

Return to the product overview and documentation map.

Build your first dashboard

Walk through creating and publishing your first dashboard.
Last modified on August 18, 2026