Working with related content - Unlock Tana free course excerpts (5/5)

TL;DR

References automatically surface at the bottom of a node whenever that node is mentioned elsewhere, providing quick context.

Briefing Cornell Notes

Briefing

Object-based workflows in Tana become far more usable once related information can be resurfaced on demand. The excerpt’s core focus is how to pull context back into view through three mechanisms: references, search nodes, and the related content feature—each designed to reduce manual hunting across a workspace.

References appear at the bottom of a node and automatically surface when that node is mentioned elsewhere. In the demo, adding a new sentence that references the “Logistics optimization project” causes the project’s references panel to pop up, acting as a quick “points of departure” for follow-on reading.

Search nodes then provide the real retrieval engine. They can be created in three ways: starting a node with a question mark (e.g., “? create search node” followed by a name), using command lines (Ctrl+K / Cmd+K) to “find nodes” with filters such as tags (e.g., hashtag lesson) and field constraints (e.g., needs update equals yes), or creating them from a Super tag page by opening a tag view and adding it as a list. Once created, search nodes can be configured via search options—most notably by opening the query editor to build structured queries. That editor supports combining different criteria, including super tags, node fields, and plain-text keywords, and it can display results in formats like tables. A key nuance is terminology: “query” and “search node” get used interchangeably in conversation, but the search node is the container while the query editor holds the structured query logic.

The excerpt’s capstone is related content, a newer feature that automatically contextualizes information. In the demo workspace, a “today” view includes an agenda-like related content block that contains a search node defined by Tana. The workflow is then customized: the user removes irrelevant items (like “Project tasks” that aren’t needed on the right side) and rebuilds the block so it shows only tasks related to a specific project. This is done by creating a search node inside related content and setting the query to match tasks whose related project is the parent—making the command universal rather than tied to one specific project instance.

After adding a task such as “send clients feedback on proposal” and setting its related project to “Logistics optimization project,” the related tasks appear in the “today” panel. The result is a focused navigation layer: whenever the user works inside a project, the workspace surfaces only the content that belongs to it. The excerpt also clarifies a practical difference: moving a search to related content changes its scope. A generic search node might list all nodes tagged as “task,” but the related-content version respects the parent constraint so it returns only the project’s tasks. The series ends by emphasizing that these tools—references, search nodes, and related content—make object-based work feel connected instead of fragmented.

Cornell Notes

The excerpt explains how Tana resurfaces context using references, search nodes, and related content. References automatically appear when a node is mentioned, giving quick starting points. Search nodes act as structured retrieval tools: they can be created via “? create search node,” command-line filters (Ctrl+K / Cmd+K), or from tag views, then customized through a query editor with fields, super tags, and keywords. Related content builds on search nodes by contextualizing results to the current object—such as showing only tasks whose related project is the parent. This matters because it turns scattered information into a focused, navigable workspace without manual searching.

How do references help when working across nodes in Tana?

References show up at the bottom of a node and appear automatically when that node is mentioned elsewhere. In the demo, mentioning “Logistics optimization project” in a new line triggers the references panel for that project, acting as a quick “point of departure” for related work.

What are the three main ways to create a search node?

First, start a node with a question mark and create a search node (e.g., “? create search node” then name it). Second, use command lines via Ctrl+K / Cmd+K to “find nodes” and apply filters like a tag (hashtag lesson) and field conditions (e.g., needs update equals yes). Third, create from a tag page—such as opening a Super tag view and adding it as a list to generate another search node.

What does configuring a search node involve, and what kinds of criteria can it use?

Search nodes have search options where the query editor can be opened. The query builder supports combining criteria such as super tags (e.g., hashtag super tag), node fields (e.g., filtering by a field like “act” or other structured attributes), and plain-text keywords. Results can be rendered in views like tables, and the node can be expanded/collapsed for navigation.

Why does the excerpt warn that “query” and “search node” can be used interchangeably?

The structured logic lives in the query editor, but people often refer to the whole block by the query’s name. The excerpt notes that the visible names may change, so it’s useful to remember the distinction: the search node is the container, while the query editor holds the actual structured query.

How does related content differ from a plain search node?

Related content contextualizes results to the current object. A plain search node might list all nodes tagged as “task,” but a related-content search node can be constrained so it returns only tasks related to the current project. In the demo, the query uses a parent relationship (related project is parent) so the “today” panel shows only the project’s tasks.

What does the “parent” constraint accomplish in the related content example?

Using “related project is parent” makes the related-content block universal: it isn’t tied to one specific project instance. When a task is created and linked to “Logistics optimization project,” the related tasks appear automatically in the project’s contextual panel, even though the block was defined generically.

Review Questions

When would references appear at the bottom of a node, and how is that triggered?
Describe two different ways to create a search node and one way to refine its results using the query editor.
In the related content setup, what role does the “parent” relationship play in limiting results?

Key Points

1
References automatically surface at the bottom of a node whenever that node is mentioned elsewhere, providing quick context.
2
Search nodes can be created via “? create search node,” command-line filtering (Ctrl+K / Cmd+K), or from tag views like Super tags.
3
Search nodes become truly useful when configured through search options and the query editor, which supports super tags, structured fields, and plain-text keywords.
4
“Query” and “search node” are often used interchangeably in practice, but the query editor contains the structured logic while the search node is the container.
5
Related content turns a search into a contextual panel by constraining results to the current object (e.g., tasks whose related project is the parent).
6
Moving a search into related content changes its scope: a generic task search lists all tasks, while the contextual version returns only the relevant subset.

Highlights

References act like automatic breadcrumbs: mentioning a node elsewhere brings its references panel into view.

Search nodes can be built quickly—question-mark creation, Ctrl+K/Cmd+K filters, or tag-based list creation—then tuned with a query editor.

Related content is the contextual layer: it surfaces only the tasks tied to the current project using a parent constraint.

A plain “task” search returns everything tagged as task, but the related-content version respects the project relationship.

Topics

References
Search Nodes
Query Editor
Related Content
Contextual Navigation