In most applications, the filter panel is where power users live and also where platforms run out of expressiveness. "Status is Open" and "Created in the last thirty days" cover the easy cases. Anything beyond that — compound conditions, filters across relationships, parameters that users can tune, slices that deserve to be saved and shared — tends to require a developer, or a separate reporting tool, or a spreadsheet. The query builder closes that gap. It gives people who aren't engineers the ability to describe exactly the data they want, save that description as a named entity, and reuse it everywhere.
Queries are first-class entities on the platform. They're stored, named, permissioned, translatable, and shareable, and they live in the same object model as everything else. That matters for two reasons. First, it means a query isn't trapped inside one view — the same query can feed a table view, a kanban, a scheduled email, an automation's iteration, a REST endpoint, and a homepage widget, all at once. Second, it means queries can be managed centrally: an administrator can audit them, adjust permissions, delete stale ones, and document them the same way they'd manage any other part of the implementation.
The builder itself is visual. Conditions combine equality, ranges, containment, starts-with, regular expressions, existence checks, and filters that walk relationships to the properties of related records. An Invoice query can filter by amount > 5000, by due date in the past, and by customer.country = Germany in a single screen, without anyone writing a join. Conditions combine with AND and OR, and can be nested, so a mildly complicated slice — "customers in Europe with at least one overdue invoice OR with a balance above a threshold" — is a readable structure rather than a page of prose.
Parameters are where queries stop being static and start being reusable. A parameter is a named input the query exposes — region, since, assignee — with a declared type. When a view uses the query, it can either lock a parameter down to a specific value, offer it as a user-facing control, or leave it hidden with a default. The same deals in a region query can drive three views: one for North America (parameter fixed), one where a user picks any region (parameter exposed), and one that defaults to the user's own region but allows override (parameter defaulted but editable). Three views, one query, one source of truth about what "a deal" means in this context.
A small refinement worth knowing about: parameters come in fixed, default, and hidden variants. Fixed parameters are locked by the view. Default parameters arrive with a starting value but remain editable. Hidden parameters are invisible scaffolding — filters that the system wants to carry but that users shouldn't touch. Those three modes cover almost every pattern that comes up in practice.
Sorting is multi-column, with direction per column, and the query's default sort becomes the default sort of every view built on it. Groupings and calculations are configured at the query level too, which means a query described once as "grouped by region, summed by amount" is available in that shape everywhere — including in the automation that emails a weekly summary, and in the export that lands in the finance team's spreadsheet.
Query preview is the builder's small but genuinely important convenience. As you build, a live preview shows the current result set. You can see the effect of adding a condition before you commit to it; you can spot the accidental filter that's excluding too much; you can validate that a parameter is doing what you think it is. That tight feedback loop is what lets non-developers build queries that actually work, without a round-trip through someone else.
Query descriptions round out the authoring experience. A short paragraph attached to a query tells other users what it's for, what parameters mean, and what the expected use is. When the list of shared queries grows to dozens or hundreds, those descriptions are the difference between a well-used shared library and a graveyard of queries that nobody remembers building.
Queries also power more than views. Automations iterate over queries — a scheduled task can run every night on the output of a query and email a summary, or send a notification per row, or update every record that matched. List actions inside forms can be driven by queries. API endpoints can be parameterized by queries. Once you see a query as a portable piece of logic rather than the guts of a filter panel, its reach becomes clearer.
The advanced filtering article goes deeper into nested conditions and subqueries for cases where a single flat set of conditions isn't enough. The saved queries and filter lists article covers how users share queries with each other and with the rest of the tenant. And the views article shows how a query becomes the lens people work through every day. All three are natural follow-ups; the query builder is the foundation under each of them.