How I organize my Logseq Templates

Logseq templates hinge on two key properties: a “template name” that’s invoked via `/template`, and a “template include parent” toggle that controls whether the parent block is included when the template is inserted. In practice, setting include parent to false makes templates behave like reusable page fragments—useful for generating structured content such as meeting notes inside a journal—while setting it to true turns the template into a more block-centric insert.

A concrete example shows how the template name property becomes the lookup key. When the template is defined with a name like “project,” typing `/template` and selecting that name inserts the template content. The inserted block can include dynamic date logic using Logseq’s human-readable future-date syntax (e.g., “deadline in two months”), which resolves into a fixed date link. That means templates can prefill time-sensitive fields without manual editing each time.

For meeting capture, the template can be structured as a block with sub-blocks. Selecting a “meeting” template inserts a top-level meeting block along with nested content such as tags (e.g., a “meeting” tag), an “attending” property, links to people, and sections for notes and action items. The include-parent setting matters here: keeping the parent out prevents unrelated elements from being pulled into the inserted structure, so the template lands cleanly where it’s meant to be used.

On organization, the creator describes two working systems for managing many templates.

The first system organizes templates by type. Each “type” (like a “book”) has its own page that contains both a table listing elements of that type and the template for creating those elements. To find templates scattered across the graph, a dedicated “templates” page uses a query that selects any block with the `template` property—giving a single consolidated view of all templates.

The second system adds hierarchy so templates are navigable without relying on a catch-all query. It splits into two layers: a page per type (e.g., “project” or “book”) that holds a query for the elements, and separate pages named like `template/<template-name>` (e.g., `template/project`). Those template pages contain only the template itself. This structure enables quick access via partial navigation (typing “tem” then “projects” surfaces the right template page), keeps the type pages clean (no template clutter), and produces a visible hierarchy in the sidebar such as “template meeting” and “template project.”

Both approaches require maintaining template names for discoverability, but the hierarchical method trades a bit more upfront organization for faster, cleaner browsing. The preference currently leans toward the hierarchical structure, with openness to revisiting the type-based approach later as the Logseq setup evolves.