Report
What It Is
A report is the presentation staff return to when they need a recognizable view of their data. A financial listing, a table of records and a dashboard can all serve that purpose. The report retains a name, owner, audience and layout. Its saved questions remain separate sources, so the presentation can be maintained without taking ownership of the business records it shows.
The catalog brings customer reports together with Rhythm’s built-in entries. Customer reports are stored records. Built-in reports are delivered with the console and can serve as starting points for a saved copy. A person allowed to create reports owns the copy they make; it begins as their private work.
Report identity remains separate from the name and from the data returned today. Names distinguish an owner’s reports, while the saved layout describes how later executions are presented. A source change can therefore require review even when the report’s own layout has not changed.
What It Is Not
A report does not grant the data permissions needed to run its sources. A saved question describes what to ask, while the report describes how to present it. A rendered file is a separate completed execution that can outlive the report record. A dashboard belongs to the report family, rather than creating a second catalog or a separate audience system.
How It Is Used
Staff browse their own, shared and built-in entries, open a useful presentation and save a copy when they need their own arrangement. Authors share with selected roles or the organization. Platform checks source audiences before accepting that share. Readers run the data with their own access. Read Only colleagues can consume shared reports without acquiring create or copy powers.
Managers maintain stored reports across owners. Version checks prevent an older editing session from silently replacing a later change. Catalog filtering checks visible source questions and their base datasets; it does not validate the complete source query. A report can consequently appear in the catalog and still fail during execution because another part of its question is unavailable. Product should treat discovery and successful execution as separate assurances.
Its Facets
Kind. Coded, table, designed and dashboard presentations use the same retained report structure while supporting different viewing and file behaviours.
Audience. Private, selected-role and organization sharing control discovery. The source audience limits how far sharing can extend.
Sources. Ordinary reports identify one saved question. Dashboards record their distinct widget sources. Dependencies block source deletion and explain changed-definition warnings.
System reports. Built-in entries ship with the console. Their visibility is a console responsibility rather than the stored-report catalog’s responsibility.
Widgets. Each dashboard element obtains its own source result. One unavailable source can fail independently of the remaining widgets.
Rendered file. Exporting creates a separate rendering request evaluated as the person who asked for it. Supported formats depend on the report kind.
How It Relates
Queries supply data definitions and datasets supply their vocabulary. Export records preserve rendered files; schedules arrange repeated delivery. Deleting a report releases its query dependencies and pauses its schedules while completed files follow their own retention. Accounting remains responsible for accounting figures and business interpretations.
What It Could Become
The product should settle ownership handover and whether report history or catalog pins deserve supported user flows. Reporting’s approved plan confirms selected decisions while product acceptance remains pending. Later reporting work should resolve the gap between catalog readability checks and complete query execution.