Challenge 2: Build a Content Consumption Pipeline

Click here to download today’s training graph.

Hopefully, you’ve been able to spot patterns in your notes and fetch them using queries. Search is an important use case for queries, but there’s much more possible with them. For the rest of this week, we’ll leverage our knowledge of queries to manage processes.

A process is nothing more than a series of steps to achieve a goal. The goal of today’s challenge is to build a collection of content you can dive into when it’s relevant or when you have time.

While there are many apps and services to capture content for later consumption, we’ll build our own barebones structure right within Logseq. Using browser extensions or Logseq plugins, you can gradually automate this content collection process.

To design and build better processes, it’s useful to know a thing or two about Systems Thinking. If this term is new for you, first read these notes (make sure you’re running the latest version of the training graph).

In Systems Thinking, there are three main components: inputs, movements, and outputs. If you’re clear on your goal (the output) and know what materials you’re working with (the inputs), it becomes much easier to define the steps to get to the goal (the movements).

Let’s see how we can apply Systems Thinking to our content consumption pipeline.

Systems Thinking applied to content collection


  • Content you wish to consume.


  • Find a piece of content (tweet, article, video, etc.) you want to consume and think about later.
  • Copy the URL of the content from the browser’s address bar.
  • Run template in Logseq and paste URL.
    • You can automate this step using some text expansion tool on your device.
  • Resurface content when it’s opportunistic to consume and digest (taking notes of your insights).


  • Highlights and notes that can be used for output (memos, blog articles, papers).

Introducing tasks

To help us manage the (short) process of capturing and revisiting content, we’ll mark every piece of content as a task.

If you’ve been using Logseq for more than a few days, you’re probably already familiar with the TODO or LATER keywords. When placed at the beginning of a block, a keyword turns the block into a task.

Apart from TODO and LATER, there are also other keywords that denote the status of the task: NOW, DOING, and DONE. These are part of two different “flavors” or workflows of task management that Logseq ships with.

The two possible task workflows are:

  • LATERNOWDONE (the default workflow)

To change your preferred task workflow, go to the Editor tab in Settings:

What’s nice about the keywords is that we can use them as values in the task query filter, like so: {{query (task todo) }}. Replace the todo keyword with any of the other available values for tasks.

It’s important to note that when using the task filter in a query, the query will only look for the search terms on a per-block basis. In other words: it will not look across an entire branch to find matching terms. This is similar to how block properties work.

Speaking of which…

Correction: this is how block properties work

In Friday’s lesson, I had incorrectly stated that block properties are applied to the whole branch they’re a parent of. However, some alert community members pointed out that block properties only apply to the block they’re part of. I’ve updated Friday’s lesson accordingly (see the section about the property filter).

If you’re looking to combine properties with other filters in a query, make sure the properties you’re querying on are page properties. To apply a property to an entire page, make sure it’s placed in the first block of the page.


For today’s challenge, you need to build a series of queries that each represent one step in the content consumption process. The goal is to end up with useful highlights and notes from content. The starting point for each piece of content is getting collected.

Follow the instructions below to get a minimum variable workflow. Experiment by collecting more resources, adding properties, and creating different combinations of queries.

Build a capture template

  • Create a template to quickly collect and categorize content, containing:
    • The TODO keyword
    • The title of the content
    • The URL to the content
    • An author:: property
    • A type:: property
    • A tags:: property

Build a collection of content

  • Use the template you’ve built to collect some content. Make sure to at least add values to the type:: and tags:: properties.

Build a process to consume content

  • For each tag value used, write a query that fetches all TODOs.
  • To create inboxes for different contexts (reading, listening, watching), split out the collected content based on type.
  • Think of what steps you’d take to consume a piece of content. Add these as values to a status property, or use the built-in task statuses. Write a query for each step in the process.

Questions? Insights?

If you have any questions or insights related to today’s challenge, please post them in this forum thread.


I am really enjoying these challenges. The number one benefit that I’m noticing is that I’ve learned how to troubleshoot my queries more effectively. In the course on the Boolean Logic, @Ramses taught us to start with the simplest query and then work outwards.

When I’m not getting the expected results from a query, I start with the simplest query and then work outwards, and am actually having success! This is a huge breakthrough for me.

Thank you, @Ramses!


This is the key! Even though it’s not necessary to become a coder, it does help to use some of the techniques that coders use. One such trick is to start with the smallest working piece of code, and then keep adding small functionality while testing the code continuously.

Thank you for sharing your insight, @AgedLace :pray:


Can sort-by only be used for dates? I would have thought something like {{query (todo todo (sort-by property type))}} would give a list of block with the todo status sorted into the tags used in their block properties under the type key. Or have I just got some syntax wrong?

Your syntax is wrong in three ways:

  1. You need to use the and filter because you’re using more than one filter value.
  2. You need to separate the (task todo) and (sort-by) values. By the way, it’s no longer (todo); it’s now (task) (as in: (task todo), (task doing), (task done))
  3. After sort-by you need to enter the key, which is type (not property, because that’s the name of a query filter).

Your query should be:
{{query (and (task todo) (sort-by type asc)) }}

Keep in mind that the type:: property has to be part of the same block as the TODO if you want it to appear in the query results.