Anyone who has put real effort into composing a filter has had the same thought afterward: I'd like to have that again tomorrow. And the thought after that: my colleague could use it, too. Without a mechanism to save and share queries, every user rebuilds the same slices each morning, and the same knowledge has to be recreated on every new hire's first week. Saved queries and filter lists close both gaps and layer on the governance that keeps a shared library from turning into a landfill.
At the simplest level, private saved queries are the save button most users want. Configure a query that actually answers your question — add the conditions, set the parameters, choose the sort — and save it with a title and short description. It's yours, scoped to you, available from the query switcher in any view on that type. Tomorrow morning you'll open the view and click the saved query's name, and you'll be looking at the same slice you curated yesterday, refreshed against the current data.
Shared queries extend the same mechanism to colleagues. A query can be saved as visible to a specific role, to a team, or to the entire tenant. A sales manager crafts "deals worth following this week," shares it with the sales team, and that definition becomes part of the team's shared vocabulary — the same query in everyone's switcher, the same semantics no matter who's looking. Team discussions about "the follow-up list" stop ambiguously referring to slightly different slices in each person's head.
Query templates are the curated layer above that. An administrator publishes a query at a defined publication level — system-wide, tenant-wide, role-specific, user-specific — and it appears as an option for the audiences that level permits. The classic pattern is a set of canonical operational queries ("overdue this week," "assigned to me," "unassigned") curated once by an admin and inherited automatically by every new user in the relevant role. New hires aren't staring at an empty query switcher on day one; the team's institutional knowledge is already available to them.
Filter lists are a related but distinct concept: a separate entity that curates small, pre-defined filter sets and exposes them to users as a compact palette. The use case is different from a full query. A query is a complete specification of the data slice — conditions, parameters, sort, grouping, the works. A filter list is more modest: a named handful of pre-set filters that a user can apply with a click within whichever query they're already in. A filter list might contain This month, Last month, Year to date, All time as quick time-range shortcuts. Users compose filter lists for themselves and share them the same way queries get shared; admins publish standard filter lists to roles. When what you want is a small toolbox of ready-made slices rather than a complete saved view, a filter list is the right shape.
Default query per view is the convenience touch that makes the system feel alive. Each user can mark one query inside each view as their default. That's the one they land on when they open the view, without having to pick from the list. If they prefer a different starting point today, they can switch — and switching inside a view doesn't lose the user's position, their selection, or their local overrides. The view stays the view; the query underneath is a selectable lens.
Governance is what keeps a shared library livable over time. Administrators can control who is allowed to publish tenant-wide queries — a permission that typically sits with a small group of implementers — so the shared catalog doesn't accumulate half-finished drafts. Individual queries carry their own edit and delete permissions, so a team-shared query can be curated by a team lead without risk of a passing user modifying it. Descriptions are saved alongside each query, which matters when the library grows past a few dozen entries and users need to remember what each one was for.
Queries reach beyond the UI, too. The REST API addresses saved queries by their name, which means a partner integration or a custom frontend can ask for the results of high-value open deals by name, and the API respects parameters, permissions, and filters exactly as the UI would. That closes the consistency loop: the same data slice definition drives the internal view, the external integration, and any scheduled automation that happens to iterate over it.
Between the query builder, advanced filtering, and saved queries, the platform gives users a way to describe the exact data they need, to preserve that description, to share it with the right audience, and to use it wherever data is consumed. For teams whose real competitive edge is a small number of well-understood data slices — the questions that separate good operators from great ones — this combination is where that edge gets encoded, maintained, and passed on.