Query

What It Is

A query is a question expressed in Rhythm’s data vocabulary. It might ask for people in a region, records changed during a period or totals grouped by a classification. The definition chooses a base dataset, values to display, conditions and ordering. Related datasets and grouped calculations can extend the question. Staff work with those choices rather than writing a database statement.

The same idea appears in several forms. A draft supports exploration. A saved query retains an owner, name and audience so the question can be reused. An application recipe offers a maintained starting point. An Explorer view preserves an arrangement suited to a record list. These belong together because they describe questions and their reuse, rather than separate business record kinds.

A saved question’s identity remains distinct from its name and from the records its latest run happens to return. Its owner is part of that retained identity. Changing a definition can change later results without creating new source records.

What It Is Not

A query does not determine the appearance of a board pack or dashboard; that belongs to its report. It does not become a file until exported. Its dataset supplies the available vocabulary, whereas the query selects a particular question from that vocabulary. A recipe is an origin for an independent draft, rather than a live link that rewrites every saved derivative.

How It Is Used

Staff build and validate questions, inspect their results and retain the useful ones. Sharing lets colleagues discover a definition while execution continues to use each colleague’s access. Read Only staff can read shared work without acquiring write powers. Customer administrators maintain shared queries, while customer-private queries remain outside their ordinary management view. Rhythm staff access is a separate support exception.

Reports and schedules make dependencies on saved questions explicit. A proposed audience change can be refused because a wider report still depends on the question. Deletion can likewise be blocked by a report or schedule. Applications that use questions as populations enumerate the matching identities as the named person and validate that access again as work continues.

Its Facets

Draft and saved query. Exploration becomes durable when staff save a named definition. Exact criterion values remain part of that definition.

Audience. Private, selected roles and organization visibility describe who can find the question. They do not grant its underlying data.

Ask-when-run value. Inputs let one question cover changing periods or selections. Declarations and supplied values must agree.

Whoever runs it. A personal criterion lets one shared question refer to each runner’s own work.

Refinement. Reports add narrowing and presentation choices while retaining the stored population boundaries.

Recipe. A released starting point supplies a concrete independent draft after its values are filled in.

Explorer view. A list arrangement carries a recipe anchor and reusable display choices.

Navigation session and selection. Navigation keeps a bounded window of identities and reads again at some window edges. Selection supplies a bounded population for another application to act on.

Generated query. A proposed draft can come from a written request and still needs review and ordinary execution checks.

How It Relates

Datasets provide the model. Reports provide presentation, exports preserve individual runs and schedules automate delivery. Security provides current role membership. Internal dated evaluations reuse the query vocabulary for application conditions without becoming staff-saved queries.

What It Could Become

The product should clarify ownership handover, future team visibility and the place of retained pins in the interface. Navigation also needs an explicit decision about stability across renewed reads. These extensions should preserve independent drafts and the distinction between a shared question and access to its data.