Skip to main content

Reporting & BI intelligence

Your data estate lives in databases; your reporting estate lives in BI tools. The Reporting tab (Conversation → Reporting in the app) makes that estate a first-class citizen, in both directions:

  1. Import & map — connect Power BI, Tableau, Qlik or OBIEE and trace every report field down to the physical tables, columns and entities it reads.
  2. Compose — build KPIs, chart components, reports and dashboards from your governed semantic model, by hand or by describing them in plain language.
  3. Publish — send any composed report out as Excel, Google Sheets, Metabase, Power BI, Qlik, Tableau or OBIEE — one definition, many outputs.

Everything is component-based and reuse-first: reports are assembled from modeled measures and dimensions (never LLM-invented SQL), components are shared across reports, and the chat recommends an existing report before generating a new one.

The tool switcher​

The Reporting page is tool-centric: pick a tool tab at the top (All · Power BI · Tableau · Qlik · OBIEE) and everything scopes to it — the connections strip, the report inventory, and the Builder's default export target. Connecting happens right on the page; there is no detour through Connectors (though the same tools also appear as gallery tiles under Connectors → Add → Cloud → BI & Reporting).

Importing a reporting estate​

Each import tool supports a metadata upload and, where the vendor allows it, a live connection:

ToolUploadLive connection
Power BI.pbit template, model.bim / TMSL JSONAzure AD app (tenant:client:secret) — scans all visible workspaces
Tableau.twb workbook, .twbx packagePersonal Access Token — workbook inventory (fields need the upload)
Qlik.qvs load script, app-metadata JSONQlik Cloud API key — apps + loaded data models
OBIEEcatalog analysis XMLSOAP catalog walk (server URL + catalog user)

Two conveniences for large estates:

  • Batch import — upload a .zip of many exports; it becomes one connection whose scan profiles every report inside.
  • Binary formats (.pbix, .qvf, .rpd) can't be parsed — the import dialog tells you exactly what to export instead.

How mapping works​

Every parsed report field — including DAX measures, Tableau calculated fields and custom SQL, Qlik aliases and OBIEE column formulas — is resolved against your discovered model in three passes. Custom SQL gets real column-level lineage: the SQL is parsed (aliases, joins and subqueries resolved), so a report built on SELECT o.freight, c.country FROM orders o JOIN customers c … maps to the actual orders and customers columns, not to the aliases. Then:

  1. Exact name match against real tables and columns.
  2. Canonical matching — case, spaces, underscores and common aliases (Customer Num → customer_id).
  3. An LLM pass that reads the tool's skill file (its naming conventions, editable by a super-admin) for the leftovers.

When a matched column is bound to an entity, the field links to that entity and attribute. The Catalog shows the result per report: a coverage bar, and per field the report-side reference, the mapped table.column, the entity chip, and a badge showing which method mapped it and at what confidence. Your ✎ manual fixes are pinned — re-maps never overwrite them, so the mapping learns from you.

Imported reports teach the query engine​

The mapping is not display-only:

  • Planner hints — every mapped report becomes a grounding example for the NL query planner: a "Monthly Freight by Shipper" report teaches it which entity, measure and dimension freight questions resolve to.
  • Measure harvesting (✚) — a report's DAX/expression measure can be lifted into the entity as a real measure, so queries answer with the same numbers the company's reports show. Only simple single-column aggregates are lifted; anything fancier is skipped, never mis-translated.
  • Import to Builder (⇪) — one click converts an imported report into editable Builder components bound to your entities (harvesting its measures first) — a legacy report becomes a governed, queryable asset you can re-publish to any tool.

Composing reports (the Builder)​

The Builder manages four kinds of objects in a hierarchy — dashboard ⊃ report ⊃ component / KPI:

  • A KPI is an entity + measure (+ optional dimensions and target).
  • A component is a chart (value / bar / stacked bar / line / pie / table) over an inline metric query or a saved query.
  • Components and KPIs linked from several parents are shared (⧉ badge) — deleting a dashboard removes only its links, never the shared parts.

Every part carries:

  • an explanation — auto-written by the LLM (editable, ✨ regenerable), stating what it shows and how it is computed;
  • a live preview (▶) through the normal query engine;
  • a { } Query view — the structured query it runs and, after a preview, the actual SQL the engine generated;
  • a lineage graph (❄) — the part → its entities → the physical tables they bind to.

Ask for a report in plain language​

The 💬 box in the Builder accepts a description in any language — "a sales dashboard: monthly revenue by country, top shippers by freight, and a total-orders KPI". Two things make it trustworthy:

  • Reuse first. Before generating, the assistant checks whether an existing composed or imported report already answers the ask, and recommends it instead (with a "Generate anyway" override). This is the anti-sprawl guardrail. Under the hood the candidates are ranked by hybrid retrieval — semantic (embeddings) + full-text search fused with RRF — over both your composed reports and the imported BI catalog, so the match holds up even on paraphrased or non-English asks.
  • Grounded only. Generated parts bind exclusively to real entities and measures from your model; anything it can't ground is reported as skipped, never invented.
The assistant needs an AI provider

The 💬 box and ✨ suggestions require an AI provider (Anthropic, a local OpenAI-compatible server, or Bedrock) configured by an admin in Settings. The Builder itself — creating KPIs, components, reports, publishing — works without one.

✨ Suggest KPIs proposes ranked KPI candidates from your model and the questions users already ask — one click adds each as a real KPI with its rationale prefilled.

Publishing​

The bottom of every report's editor is the Publish area, split into ⬇ Download file (pick a format, export) and ⤴ Publish live (push to a connected tool — each live target is shown even before its connector exists, with a hint on how to connect it). One definition, any output:

TargetKindWhat you get
Exceldownload (default)A self-managed .xlsx: raw entity rows on Data - sheets, report tabs computed by live SUMIF/COUNTIF formulas over them, native Excel charts, KPI headline numbers, and a cover sheet with every part's explanation. Edit or extend the data — everything recalculates. Opens unchanged in Google Sheets and LibreOffice.
Google Sheetslive pushConnect once with a Google service-account key (no OAuth flow); publishing creates a spreadsheet with the same data-tabs + formulas structure and returns the link.
Metabaselive pushConnect with host|api-key; each part is compiled to SQL by AgentData's engine and lands as a native-SQL card on a new dashboard. Cards run against Metabase's own connection to the same database — the dashboard stays live.
Power BIdownload / live pushDownload model.bim (TMSL) + .pbids, publish a semantic model and bound report to Microsoft Fabric, upload a PBIP ZIP to SharePoint, or create a standalone push dataset carrying each part's computed rows. Fabric publishing currently creates an Import-mode model and empty report canvas; configure model credentials/refresh and visuals in Fabric.
Power BI project (PBIP)downloadA Git-friendly PBIP/TMDL project folder — Power BI Desktop opens it directly, and Fabric REST updateDefinition accepts it. The semantic model carries the same governed tables, typed columns and DAX measures as the .bim.
QlikdownloadA .qvs load script (LOAD + SQL SELECT per entity table).
TableaudownloadA template .twb workbook — one datasource per entity with its columns and calculated measure fields, ready to drag onto sheets.
OBIEEdownloadAn analysis XML. OBIEE is positioned read-only: import, explain and recommend — new reports go to the modern tools (a migration wedge for legacy estates).

Flows can export to Excel too: any flow CSV export downloads as a typed .xlsx with ?format=xlsx.

Governance & trust​

  • Reports are composed only from modeled measures and dimensions — there is no path where the LLM writes SQL into a report.
  • Every part explains itself and shows its query, its generated SQL and its lineage down to physical tables.
  • Shared components mean one definition of "revenue" — used by many reports, fixed in one place.
  • The reuse-first chat prevents duplicate-report sprawl.
  • Publishing respects the same role model as everything else: viewing is open, composing needs editor, connecting tools needs admin.

Next steps​