Building One
A saved query is created from the Query Builder and then given a name and settings of its own.
Where to find it
Architect Panel → Data:
- Query Builder — building a query visually
- Custom Query Views — saved queries, then View Actions on a row
Build the query first
In the Query Builder, where you can see the results as you go. Saving a query you have not run is how a report that returns nothing reaches somebody’s dashboard.
Bound it
A saved query with no date bound returns more every year. Something that ran in a second when it was written can take a minute two years later, and the person who notices is a user.
Where the question is about recent work, say so in the query.
Row actions are a row action
A saved query can carry its own actions on its results — reached through View Actions on the query’s row. Each has a name, a button style and what it does.
That is what turns a list into a worklist: see the twelve overdue cases, and act on one without leaving the list.
Keep actions few and unambiguous
Two or three. A results list with seven buttons per row is one where somebody clicks the wrong one, and on a list of records that matters.
Check the columns are readable
A query returning internal identifiers and raw codes is a query somebody has to interpret. Return the names people use, and only the columns that are needed to decide something.
Run it as somebody else
The critical test, given how saved queries work. Confirm what a different person sees when they run it, because the query does not narrow itself to them.
Test the empty case
A list with no rows should say so clearly. An empty table looks like a fault, and it generates a support contact every time.
Write down what it is for
Alongside the name. Six months later somebody will ask whether this query still means what its title says, and the answer is much easier if the intent was recorded.
Worked example
A saved query returning overdue cases was bounded to the last twelve months, given two row actions — assign and close — and tested by three people with different access. One of them saw cases from another team, which was corrected before the query was shared.
Recommendations
- Run it in the builder before saving.
- Bound it by date so it does not grow forever.
- Two or three row actions, no more.
- Run it as somebody else before sharing it.