Queries are saved filters that stay live. You set rules once (object types, properties, tags, dates), and Capacities keeps showing whatever matches. Because a query is an object, you can pin it beside an object type dashboard, embed it on a project page, or drop it into a template so every new person or project starts with the same layout.

This page is about workflows: what to build, where to put it, and how it behaves day to day. For query types, the filter editor, variable queries, grouping, and limits, use the Queries reference. If you are deciding between a saved filter and a hand-picked list, see When should I use a query instead of a collection?.

Saving a filter as a query

You can build queries from scratch, but most people start from a filter they already use.

Open an object type dashboard and narrow the list until it shows what you want. Use Filter and Sort the way you would for a one-off search (filtering). When the results look right, choose Save as query, and give it a title and icon. The query is saved as a section on that dashboard.

A bookshelf that updates itself

Many reading workflows use a Book object type (from the template gallery or your own design) with a datetime property such as Finished on.

Finished books

The only habit you need is to set Finished on when you are done. Pair that with a maintenance query for books marked done but still missing a date, and your display queries stay trustworthy.

Open your Book type from the left sidebar. Click Filter and restrict Finished on to the period you care about (this calendar year, or a rolling window like “on or after 1 January”). Sort by Finished on so the list reads in chronological order. Save as query and name it (for example “Read in 2025”).

Each time you complete a book and fill in the date, the query updates automatically.

Your TBR list

Add a label property (or tags) for reading status on your Book type. Then build a TBR query by excluding books with your “Done” status.

For unstarted or in-progress books, use the same pattern with one change: filter where Finished on is empty.

Meetings embedded on a project page

Project objects work well as hubs: status, dates, notes, and links to resources. Meetings fit naturally as a variable query that always lists sessions tied to this project.

You need an object select property linking your Meeting and Project types (create the Project type first, then add the property on Meeting).

Open a project you are actively working on. On a new line, type /query and select your Meeting type. Open Edit query and add a filter on the property that links meetings to projects. Instead of choosing one project by name, use the variable that means this object so the embed adapts to whichever project page it sits on.

Sort by meeting date, usually newest first, so the next conversation is at the top and older notes scroll down.

From now on, logging a meeting with that project selected is enough for it to appear here.

Add the same embed to your project template. New projects open with the meeting list ready. Without variables, you would duplicate the embed per project and change the project name in the filter each time, which does not scale once you have dozens of active projects.

A person page as your meeting history

The same pattern applies to Person objects. Open a person and embed a query for 1:1 meetings where the People property includes this person. You get a chronological record on the page you already open before a call. The full meeting notes guide covers templates, calendar capture, and follow-up tasks; this section is only the query embed.

Capacities can offer a New action on the query when the rules are specific enough (correct meeting type, person filter filled by the variable, and any other fields you always use). New creates a meeting with those properties prefilled.

Put the embed on a person template if you work with many contacts the same way. One template change propagates to every person you create afterward.

Combining tags for reading and writing

Tags cut across object types. A quote, a web link, and a page can all share #learning. The tag page already gathers everything with that tag.

Often you need the overlap between two ideas: material tagged with both #creativity and #learning, for example. On a tag page, use Create query with tag, add the second tag, then save the result as its own query object (tag queries). You can rename it, embed it elsewhere, and treat it like any other saved view.

When membership should stay manual within one type, a collection may still be the better fit. See Tags vs. collections for how tags and collections differ before you rely on queries alone.

Planning pages and dashboards

A single page can act as a control centre if you embed several queries and a few pinned objects. Create the queries first (or reuse ones pinned on object dashboards), then open a page and link each query with @, setting the view to Embed (embed view). Arrange blocks in columns if you want a board-like layout. Yearly planning pages work the same way as weekly ones: the time horizon changes, not the mechanics.

Random resurfacing query

If you collect many small objects over time (ideas, research blips, quotes), most of them will not be top of mind on any given day. A query with a low Limit results and random order picks a handful each morning so you revisit and extend past notes without building a manual queue.

Create the query on that object type, set the limit (five is a common starting point), enable random ordering in the query editor (limit and random), and embed the query in your daily note template. Every daily note opens with a different subset. You still write new material in the body; the embed is a prompt, not the whole journal. For a broader daily-note workflow, see Daily notes.

Maintenance queries and processing pages

If your queries depend on properties being filled in, create companion queries that find gaps where those properties are empty. Think of them as maintenance queries.

On this page, useful maintenance filters include:

• Books marked done in a status field but with an empty Finished on
• Meetings with no linked project
• Meetings with an empty People property

To make maintenance easy, create what Beth calls a processing page: a single page where you embed every maintenance query you rely on. Open it on a schedule (or when something looks wrong elsewhere), work down the embeds, and know that finished items will show up in the display queries you use for research, planning, or writing.

The page is quick to build: create a page, type @ to link each maintenance query, set Embed, and arrange blocks in an order that matches how you think (people first, then media, then cleanup). Add or remove embeds whenever your types change.

More maintenance examples

Sources without a type tag. If one Media or Source type carries books, articles, and podcasts, distinguish them with tags (#book, #article, #podcast). A maintenance query filters that type where none of those tags apply. The processing page becomes your inbox for “label what this is” before topic queries and dashboards can trust the tags.

Objects with no backlinks. For knowledge work, objects that nothing links to may be stale. A query on Pages (or several types) filtered to no backlinks (filter by backlinks) gives you a review queue: deepen the note, link it somewhere useful, or delete it. That keeps display queries and graph views from filling up with orphans.

Relations you use in downstream queries. The same pattern applies to any property your display queries depend on: countries on locations, project links on meetings, status labels on tasks. If the display query filters on it, add a maintenance query where it is empty and park it on the processing page.

Learning prompts on the same page

Maintenance embeds do not have to be chores only. On the same processing page, add a query with a low Limit results and random order (random resurfacing query) over a type you want to explore over time, such as Country or Quote. Each visit surfaces one item you might otherwise never open.

Where to go next

• Queries reference for search queries, tag queries, backlinks in filters, and the roadmap
• Meeting notes for type setup, calendar capture, and task follow-up
• Daily notes for inbox habits and review rhythms
• Templates to ship embeds on every new object of a type
• Tags and Working with tags if tag queries are central to your setup
• Dates and daily notes for calendar behaviour and daily templates
• When should I use a query instead of a collection? when you need a manual shortlist instead of a rule