Logseq Office Hours #2: Building processes with queries

Logseq queries are essentially saved searches that let users “slice and dice” their notes by combining block structure (indentation), links, date filters, and metadata properties—turning scattered journaling or task notes into repeatable, process-driven views. The session’s core message is that getting queries right depends less on memorizing syntax and more on thinking in Logseq’s fundamental units: blocks arranged into parent-child branches, connected by links, and enriched with properties.

The walkthrough starts with the building blocks. In Logseq, every bullet is a block (the smallest unit of knowledge). Indentation creates parent-child relationships, forming branches—collections of nested blocks that behave like a tree. Queries don’t just search a single bullet; they evaluate the branch context created by indentation. That’s why indentation matters: if related content sits at the wrong level (siblings instead of parent-child), the query results change because the branch membership changes.

Links are introduced as the second foundational concept. Square-bracket wiki links create bidirectional connections between pages and also between the page and the blocks that reference it. While search can be done via text patterns, links become especially powerful when used as query terms—allowing users to treat their graph structure like an index. This sets up the idea that queries can function like custom collections: a query can return all blocks that match certain link and text conditions, effectively acting as a dynamic page of results.

From there, the session moves into query logic using filters that resemble boolean search. Users can require multiple terms with AND, allow alternatives with OR, and exclude terms with NOT. A live example demonstrates how a query that looks for blocks containing both “journal” and “sad” returns the matching branch, and how unindenting changes which blocks belong to that branch—altering results. The key takeaway is that query outcomes reflect both the content you wrote and the structural relationships created by indentation.

The session then models a practical workflow for building queries step by step: start broad, verify results, then add constraints. A journal example begins with fetching all blocks between two dates using the between date filter (e.g., April 1st through today). Next, it narrows results to blocks linked to the journal page, then further filters to morning entries by adding additional arguments (and optionally excluding evening). The same incremental approach is repeated with properties—metadata stored as key-value pairs using the :: syntax. Properties enable more precise filtering, such as returning only entries where mood equals “sad” during morning.

Finally, queries are positioned as operational tools, not just search. The session shows how templates and properties can feed an “inbox” or pipeline: blocks created by templates appear in query-driven lists, and when a property like status changes (e.g., from to-do to done), the block disappears from one list and moves to another. Table view is highlighted as a major advantage of properties, since it can render property-based columns for easier review. Q&A addresses practical concerns like where to place tags (order doesn’t matter; the query returns the last matching block in a branch) and feature requests such as dropdowns for property values and better UI/visual query building. The session ends by pointing to a community hub for workflows and learning resources, emphasizing that documentation and query explanations still need refinement based on user feedback.