Intro
Traditional Obsidian tasks are checkboxes embedded in notes. This is one of their greatest strengths: any line can become actionable without being separated from the information around it.
But Obsidian users have also experimented with treating entire notes as tasks. A prominent example is the TaskNotes plugin, which stores every task as a separate Markdown note with structured properties and uses Obsidian Bases to display those notes in lists, boards and calendars.
At first, this may appear to be a minor technical difference—instead of writing a task on one line, we give it an entire file, whats the big deal?—but this change affects the way we represent and manage work at a foundational level.
A checkbox inherits its identity and context from the note containing it. A task note has its own identity, properties, context and relationships.
After more than ten years of managing technical projects, I do not see these as competing approaches. Checkboxes and task notes serve different but complementary purposes. To understand when each is useful, we first need to define what they represent.
Actions and their representations
Before we dive too deep, let’s first define what we are dealing with here.
What is an action
At the most basic level, an action is something we intend to do to create a change. Actions can create, modify or remove something.
We can write an article, repair a machine, add information to a document or delete an obsolete file. In my object-oriented approach to project management, O3PM, the things affected by these actions are called objects.
A task-management system does not contain the actions themselves. It contains representations of them: reminders and information that help us initiate, manage and complete the work.
Both a checkbox and a task note can represent the same action. The difference lies in how independently that action can be represented and managed.
What is a checkbox
A checkbox (for brevity, I sometimes refer to these checkbox items as checks) is a lightweight representation of an action embedded within another note. It inherits most of its meaning from that note and the information surrounding it.
For example, a note called “Do the laundry” could contain the following sequence:
- [ ] Put the clothes in the washing machine
- [ ] Add detergent
- [ ] Start the washing machine
- [ ] Take the clothes out
- [ ] Hang the clothes to dry
Each checkbox describes a local step within the larger activity. The steps do not require their own files, properties or extensive explanations. Their order and the containing note provide most of the information we need.
Advantages
- They are extremely fast to create.
- They keep actions beside their immediate context.
- They make sequences of actions visible (the action in the next line is the next action in the workflow).
- They create almost no organizational overhead.
- They are easy to complete and discard.
- Several related actions can be viewed and edited together.
Limitations
- They most naturally represent a binary state: open or completed. Additional statuses usually require conventions, custom checkbox characters or plugins.
- They are more difficult to schedule, assign or manage independently (not impossible, thanks to tasks plugin among others).
- Their space for accumulating context and progress is limited.
- Relationships to people, projects and other tasks are harder to represent.
- They can easily lose their meaning when separated from the containing note.
- Adding extensive information to them can make both the checkbox and its surrounding note difficult to read.
These are not flaws in checkboxes. They are consequences of what makes checkboxes useful: they are deliberately lightweight and dependent on their local context.
What is a tasknote
A task note is a persistent and independently addressable representation of a piece of work.
Instead of existing as one line within another note, the task receives its own Markdown file. It can therefore have its own properties, links, content and history.
Here is a simplified version of the task note I used while planning this article:
Title: "• Create agenda for the task-note article series.md.md"
---
tags:
- task
created: 2026-08-24
project:
- "[[OPS - Nosy]]"
status: "[[Actively being worked on]]"
object_created:
- "[[@ Article - Task Definition]]"
object_modified:
- "[[@ Article - Rules for Task Note Creation]]"
---
## Checklist
- [x] Review the initial agenda
- [x] Separate the definition and creation-rule articles
- [ ] Complete the definition article
- [ ] Move the creation-rule article into the backlog
## Notes
- **11:31** Reviewed the existing agenda.
- **18:25** Decided to separate the definitions from the creation rules.
- **20:19** Added the first notes for the new article.
The note represents the overall piece of work. Its properties describe how that work is managed, while its body contains the local steps and information required to complete it.
From a management perspective, all checkboxes inside this task note belong to the same project, pursue the same general outcome and share the task note’s status and context. They do not need independent properties of their own.
Advantages
- They have their own identity, status and properties.
- They provide space for context, progress and decisions.
- They can be linked from several projects, objects or other tasks.
- They can contain checkboxes for smaller execution steps.
- They can be scheduled, assigned and queried independently.
- They can represent dependencies and other task relationships.
- They can preserve a useful history after completion.
- They remain understandable even when accessed outside their original context.
Limitations
- They require more effort to create and maintain.
- They produce more files and potential navigation clutter.
- They can encourage overengineering of simple actions.
- Information can become fragmented between project, object and task notes.
- Unnecessary properties can create administrative work without improving execution.
- A large number of poorly structured task notes can make finding the relevant work more difficult.
Plugins can reduce the mechanical effort of creating and updating task notes, but they cannot completely remove the organizational cost. Every independently managed task still needs some attention.
In O3PM, a task note represents an externalized intervention in an object’s lifecycle. Instead of remaining a checkbox inside the object note, the action receives its own identity while staying linked to the objects it affects. While open, the task note organizes an intended change. Once completed, it becomes part of the object’s CV: a record of what created, changed, repaired or retired it.
The synergy of tasks and checks
Task notes and checkboxes are not enemies; they operate at different levels of the same workflow.
- A task note defines an independently managed piece of work.
- Its checkboxes describe the local steps required to complete it.
For example, a task note called “Write the task-note definition article” might contain:
- [ ] Review the existing notes
- [ ] Create the outline
- [ ] Draft the introduction
- [ ] Add examples
- [ ] Upload the article to WordPress
- [ ] Share the article on Substack
Initially, all these actions belong to the same project, share the same context and contribute directly to the same outcome. Representing them as checkboxes keeps the workflow compact and visible. But actions can change while we work on them.
Suppose “Share the article on Substack” later acquires its own publication date, graphics, text variants and follow-up actions. It now needs to be scheduled and managed independently from writing the article. At that point, the checkbox can be promoted into its own task note.
The underlying action has not necessarily become more important. It has simply acquired its own state, context or relationships.
This makes the boundary between checkboxes and task notes flexible. A task note can contain many checks, while any one of those checks can later become another task note when the work demands greater independence.
Outro
Checkboxes minimize organizational cost. Task notes maximize independent manageability.
A checkbox works best when an action can remain within the context, properties and lifecycle of the note surrounding it. A task note becomes useful when a piece of work needs to establish an identity and context of its own.
A good task-management system does not force every action into the same representation. It uses the least complex representation that can hold the work reliably.


Leave a Reply