# BI and dashboards Business intelligence (BI) tools let people explore data and build reports and dashboards; doing this well means choosing how the tool reaches the data, deciding who builds what, and designing dashboards for the decisions they support. > [!NOTE] > > **Before reading** > > [Semantic layer]() ## Why it matters For most people in a company, the dashboard is the data platform. If it is slow, wrong, or shows a number that disagrees with another report, trust in all the platform's data drops. BI is also where cost and governance problems surface: an inefficient dashboard queried every five minutes, or a report that exposes data its viewers should not see. ## How it works A BI tool connects to data, lets users define charts and filters, and shares the results as dashboards and reports. Common tools include Power BI, Tableau, Looker, Apache Superset and Metabase (checked October 2026); spreadsheets with live connections fill the same role for many users. There are two main ways a BI tool gets data. Live queries send each chart's query to the engine when the dashboard is opened, so data is always current and access rules in the engine apply, but every view costs engine time and the dashboard is only as fast as the engine. Extracts, also called imports, copy the needed data into the BI tool's own store on a schedule, which makes dashboards fast and cheap to view but adds a copy that ages between refreshes and must carry its own access rules. Some tools add a third mode that reads lake files directly into the BI engine's memory, such as Power BI Direct Lake over Delta tables (checked October 2026); it is fast like an extract without a scheduled copy, but is tied to that vendor's platform. Many tools mix live queries and extracts: extracts for heavy historical views, live queries for recent data. Where metric definitions live matters. If each dashboard computes revenue itself, definitions drift. Reading metrics from a semantic layer, or at least from gold tables with the calculation already done, keeps one definition across dashboards. BI tools' own semantic models work too, as long as they are the only place the metric is defined. Two modes of use need different support. Curated dashboards, built by analysts or analytics engineers, are reviewed, documented, tested and owned, and are what executives and teams rely on. Self-service exploration lets people answer their own questions by dragging fields from governed datasets. Both are valuable; the risk is self-service results being presented as official numbers. Marking certified dashboards and datasets, as the catalog does for tables, separates the two. ``` flowchart LR G[(Gold tables and
semantic layer)] -->|live query| D1[Curated dashboard:
certified, owned] G -->|scheduled extract| X[(BI extract)] X --> D2[Large historical
dashboard] G --> S[Self-service
exploration] D1 --> U[Decision makers] S --> U ``` A dashboard is designed around a decision. It starts from who uses it and what they decide with it, shows the few numbers that matter for that, with comparison against a target or previous period, and provides drill-down for detail. Each number shows its definition, its freshness and, where relevant, whether data is still incomplete. Clutter, decorative charts and unexplained colours hide the signal. Performance comes from the data, not the chart. Dashboards over pre-aggregated gold tables are fast; dashboards that join raw tables on every load are slow and expensive. Caching in the BI tool or semantic layer helps for repeated views. Access rules must hold in BI too. With live queries under each viewer's identity, engine rules apply. With extracts, or with a shared service account, the BI tool must apply equivalent row-level rules itself, and they must be kept in sync. ## Key terms - Business intelligence (BI) Tools and practices for reporting and exploring business data. - Live query A dashboard query sent to the engine each time it is viewed. - Extract A copy of data stored in the BI tool and refreshed on a schedule. - Curated dashboard A reviewed, owned dashboard intended as an official source. - Self-service analytics Users exploring governed data on their own. - Certification Marking a dashboard or dataset as trusted and supported. ## Example The shop's daily sales dashboard for regional managers: - Purpose: each morning, a manager checks yesterday's revenue and orders against target and last year, and spots categories that need attention. - Data: revenue and order count from the semantic layer, by day, region and category; live queries under the viewer's identity, so the region row filter applies. - Layout: three headline numbers with change against target and last year; a 13-week trend; a category table with drill-down to products; a note showing data as of 06:40 and that today's figures, if shown, are partial. - Performance: the semantic layer serves yesterday's figures from a pre-aggregation, so the dashboard loads in under two seconds for the 120 managers and analysts who open it each morning. - Ownership: certified, owned by sales operations, with its revenue definition linked to the glossary. The headline and trend charts send one request to the semantic layer (simplified, not tied to one tool): ``` { "metrics": ["revenue", "order_count"], "group_by": ["order_date", "region", "category"], "filter": "order_date >= current_date - 91" } ``` The layer turns this into SQL on shop.fct\_order\_line and shop.dim\_product using the definitions from the [Semantic layer]() example, extended with a region dimension. For an EU manager it adds `region = 'EU'` to the query, so the dashboard needs no filter logic of its own. ## Pitfalls - Metrics defined in each dashboard. Numbers disagree across reports. - Extracts with no access rules. Everyone who opens the dashboard sees everything in the copy. - Dashboards on raw tables. Slow, expensive and fragile when sources change. - Every possible chart on one page. A dashboard for everything supports no decision well. - Live queries refreshing every few minutes for many viewers. Each refresh reruns every chart's query; serve repeats from a cache and refresh only as often as the data changes. ## Learn more - Stephen Few, Information Dashboard Design, 2nd edition (Analytics Press, 2013). - [Apache Superset documentation]() - [Microsoft Learn, DirectQuery in Power BI (compares live and import modes)]() ## Related [Dimensional modelling]() [Cost and FinOps]() [Row-level security and masking]() [Data quality dimensions]()