Saved Queries
A custom query view is a saved query with a name, built in the Query Builder and re-run on demand.
Where to find it
Architect Panel → Data:
- Query Builder — building a query visually
- Custom Query Views — saved queries, then View Actions on a row
Architect Panel → Data:
- Compilations — a governed alternative for reporting
What it stores
A name, the query itself, a search variant, any special tasks, its filters, and whether it is public.
The important word is query: what is stored is a fully rendered SQL statement, not a description of what to fetch.
Why that matters
Because the tenant and every literal value were baked in at the moment it was saved, and nothing about the row is re-checked against whoever runs it later.
So a saved query runs with the reach it had when it was written, for whoever can run it — not with the reach of the person running it.
Which makes them sensitive
They hold raw SQL that the platform executes, and they are on the API’s protected list for exactly that reason: anybody able to write one could execute arbitrary statements.
Treat the ability to create a custom query view as a privileged permission, not an ordinary reporting one.
Prefer a governed alternative for new reporting
Where the platform offers saved datasets that store a specification rather than a statement, use those instead. A specification is re-authorised against the current reader on every run, which is what you want for reporting that several people use.
Custom query views remain supported and are widely relied on; they are simply not where new work belongs.
Review what exists
Every saved query is a statement somebody wrote once and nobody has read since. A periodic review — what does this return, who can run it, does it still need to exist — is worth the time.
Public is a real decision
A view marked public is available broadly. Given what a saved query is, that is a decision to make deliberately rather than a convenience flag.
Name them so the purpose is obvious
"Open cases over 30 days, by team" rather than "Report 4". A saved query nobody can identify is one nobody dares delete and nobody trusts.
Worked example
An organisation reviewed its saved queries and found eleven, four of which nothing referenced and two of which returned data the current owner should not have been able to see. New reporting was moved to governed datasets and the unused views removed.
Recommendations
- Treat creation as a privileged permission.
- Remember a saved query is a stored statement, not a re-checked request.
- Use governed datasets for new reporting.
- Review what exists and remove what nothing uses.