Reporting

Self-service reporting that can't hurt production.

Business users build multi-table reports in the browser. Queries run async with timeouts and cancel, on a read-only mirror when configured, tenant-scoped always.

Most relevant for: CIO and VP / Director
The short version
  • ·Business users build their own reports across related tables, so IT stops being the report queue.
  • ·Reports run in the background with timeouts and cancel, optionally against a read-only mirror, so a runaway query cannot take production down.
  • ·Report data goes through the same security engine as everything else, so a report cannot leak across tenants.
The problem it kills

Ad-hoc reporting is either a bottleneck or a hazard.

Either every report request goes through IT and waits weeks, or business users get query access and one runaway join takes the order system down at month-end. Most companies alternate between the two.

The security question is worse: report tools bolted on beside the application usually bypass its permission model entirely.

How it works

The mechanisms, not the adjectives.

Structure-driven report builder

Users pick fields across related tables, guided by the actual schema relationships. Formula filters, runtime prompt filters, live preview, saved reports with per-user folders and sharing.

The people who need the answer build the report. IT stops being the report queue.

Async execution with limits

Reports run through the event and queue system with cancel support and runaway-query timeouts. Run history and timing metrics are kept, with retention-based cleanup.

A bad report is an annoyance, not an outage.

Read-replica isolation by construction

Report queries can run on a dedicated read-only mirror server. Writes can't hit it because the report path physically has no write route. When no mirror is configured, reports run on the primary unchanged.

Production isolation is an architecture decision, not an operations promise.

Tenant-scoped, format-flexible output

All report data flows through the same security engine, so a report can never leak across tenants. Output lands as CSV, JSON, XML, XLSX, or an Excel template merge: upload a formatted workbook and the platform fills it.

Finance gets their workbook, formatted their way, without anyone exporting and re-keying.

Walk it through

Month-end without the ticket queue.

  1. 1

    A finance user builds a report across invoices, lines, and vendors, guided by the schema's real relationships.

  2. 2

    They add a runtime prompt for the period, preview live, and save it to a shared folder.

  3. 3

    At month-end it runs async on the report mirror, with a timeout it never hits and a cancel button nobody needs.

  4. 4

    Output merges into their formatted Excel template. The numbers land in their layout.

  5. 5

    Every row they saw was tenant-scoped. The report tool had no way around the security engine, because it isn't beside the platform. It is the platform.

What this means for AI

The AI angle.

Reports are how AI answers get audited. When an agent summarizes performance or drafts a board number, the underlying question should be a governed, reproducible query over scoped data, not a model's paraphrase of a spreadsheet. This layer is what makes those answers checkable.

Related

Keep going.

Security & multi-tenancy

Tenant isolation derived from foreign keys and enforced in one data path. No filter to forget.

Go deeper

Data & instant API

Register a table and it is secured, audited, and queryable. No ORM, no per-table code.

Go deeper

Operations

The platform ships with its own ops console, real-time notifications, and full change history.

Go deeper

See it on your schema, not ours.

A fixed-price assessment gets this running over your actual data.

Book an assessment