Reports

Every datastore gets a report builder. It filters, summarises and graphs, and joins related tables without being told how.

Where to find it

Architect Panel → Data:

• Datastores — the datastore a report is built over
• Query Builder — defining a saved query

Architect Panel → Dashboards:

• Explore — the analytics alternative

What it does

• Standard reports — columns with filters and criteria, including date ranges.
• Summary reports — counts of distinct values across one or more columns.
• Graphs from either.

Automatic joins are the useful part

A report over cases can include the customer's name and the category's label without anybody writing a join, because the relationships are already described in the datastores.

That is the whole argument for building reports where the data model lives rather than exporting and joining by hand.

Where it fits

Operational reporting: this month's cases by status, overdue items, work by owner. Questions with a known shape, asked repeatedly, answered from one datastore and its relations.

Where Business Intelligence takes over

When the question spans several datastores in ways the relationships do not express, when a measure needs defining once and sharing so everybody's numbers agree, or when somebody wants to explore rather than run a known report.

The distinction worth holding: this builder answers a question about a datastore; the semantic layer defines what a number means across the business.

Do not rebuild the same report five times

The commonest waste. Five near-identical reports differing by one filter is a maintenance problem — a change to the underlying model breaks all five, and they drift apart.

Where a report differs only by criteria, use one report with filters rather than several fixed ones.

Summary reports answer more than people expect

Counting distinct values across a column is how you find data quality problems: forty spellings of a status, a category used twice, a field that is empty far more often than anybody realised.

Running one over a datastore you are about to report on is a good habit before trusting the numbers.

Permissions apply

A report shows the person running it what they are allowed to see, so two people running the same report can legitimately get different totals. Worth knowing before somebody concludes a report is wrong.

Worked example

A team builds one cases report with filters for status, owner and date range rather than six fixed variants. A summary report over the category column, run first, found two categories differing only by a trailing space — corrected before anybody reported on them.

Recommendations

• One report with filters, not several fixed ones.
• Run a summary first to check data quality.
• Use Business Intelligence when a measure must mean one thing everywhere.
• Expect different totals for people with different access.