Combining knowledge management and task management

Fedja_b

Registered
Hey guys,

With the advent of the newer generation PKMS apps such as Obsidian, Roam, Logseq, UpNote, etc. it has become possible to combine our notes (and knowledge) with task management. What is your opinion on this? Should this be avoided or are there benefits? I am particularity interested in experiences from people who have tried doing this; what are your conclusion? Were there tangible benefits or did you find it too confusing and messy?

Alternatively, is it even possible to combine the full GTD methodology with a personal knowledge management system?

Looking forward to a fruitful discussion.
 
I use Obsidian to manage a lot of my digital GTD.

I find it convenient to create project notes right from my projects list.

I like having it all synced to my phone with no effort from myself.

I like having my lists and notes as plain text files that I can access even without the Obsidian app.

That's about it from me. It's not revolutionary but I enjoy using it.
 
No reason it can't work in theory, its just that in practice, I find specialist task managers tend do the job better. They're more tuned in to the little details that make handling my tasks easier.
 
My experience is that as the ratio of total notes to embedded actions becomes larger, it often becomes harder for me to manage the project. This may be me, or a reflection of the nature of my larger projects, or both.
 
My experience is that as the ratio of total notes to embedded actions becomes larger, it often becomes harder for me to manage the project. This may be me, or a reflection of the nature of my larger projects, or both.

Oh, have I misunderstood the question? I completely agree with you. I have notes and next actions in the same app, but in different parts of it. I have a "note" for my next actions. All my next actions go there and only there. I have other "notes" for project support. They might have project plans but I don't go there to see my current list of next actions.
 
Does mixing your knowledge notes and tasks create any kind of friction? Is it better to keep clean hard edges by using separate apps (better features of dedicated Todo apps notwithstanding)?
 
I am particularity interested in experiences from people who have tried doing this; what are your conclusion? Were there tangible benefits or did you find it too confusing and messy?

Alternatively, is it even possible to combine the full GTD methodology with a personal knowledge management system?
I've moved from several specialized apps to do pieces of both PKM and GTD/Task management into a single app. I use Obsidian.

Benefits: one place for ground truth on all my endeavors, learning to use one general purpose tool very well reduces the mental clutter of remembering specialized toolsets and operating procedures, simple easy to use on all systems I use, no worries about whether it will work on my Linux box, my Android tablets, my ipad, macs or iPhone. It works everywhere pretty much the same.

Drawbacks: It takes a fair amount of time to fine tune it and decide on whether to use extra plug-ins and if the answer is yes to decide which ones and what you will do if they become deprecated.

It's totally possible to combine a full GTD system integrated with a full PKM system.
 
the question is if it can remind you of any action.
as for reference and list keeping it is fine.
also technically - how fast can you transfer the wisdom from the clarification process into your lists.

for me, the drag-drop task creation in old Outlook is unbeatable (especially if you have to attach the relevant email to the task)
 
I largely agree with Stefan Godo and cfoley and Oogiem—both in their perspective and approach.

In Obsidian, each note is essentially a file, so you can easily set up your GTD system using just a few dedicated files: one for your Inbox, one for your Next Actions, one for your Projects, and optionally, one for Someday/Maybe.
At the same time, you can use other notes for knowledge management—atomic notes, concept maps, literature summaries, etc.
Task management and knowledge management don’t have to conflict; they can coexist clearly and effectively within the same system. And with bidirectional linking, Obsidian makes it easy to connect tasks and knowledge when needed.

Also, as I’ve mentioned in other threads, when it comes to task management tools, the most flexible option is actually a paper notebook—or digital equivalents like note-taking apps.
Why?
Because they allow you to freely adapt the structure and format whenever you want.
In contrast, most dedicated task management apps are built around their creators’ specific productivity philosophies, with rigid, fixed templates. You’re forced to adapt to them, rather than being able to mold the system to fit your evolving needs.

For example:
  • Can you freely choose whether to leave completed tasks in place or make them automatically disappear?
  • Can you embed a link to a past reading note or research idea directly within a task?
  • Can you freely reorganize the layout or hierarchy of your tasks on the fly?
These are things that are often impossible or very clunky in traditional task managers—but in a note-based system like Obsidian, they’re not only possible, they’re effortless.
That flexibility makes a huge difference in the long run.
 
I would also add from a higher perspective that operating a Knowledge management system and a Task management system are both part of the second and (foremost) the third step of GTD (the question "is it actionable?" decides where to put what in the third, Organize step)

and in this sense they are strongly interconnected.
The difference is only that you have to be reminded of actions (without further need of thinking), whereas Reference material (incl. Knowledge) is useful (eventually), but in itself does not hold an action = we need NOT to be reminded of it. (it does not mean that we will not use or review it).

When zou are working on a book, the action is "draft the outline of the next chapter", and your PKM serves as a helping tool to do that action.
 
@achieve I wonder how this could be useful. The hierarchy is Project --> Action. How do you want to reorganize it?
Hi @TesTeq,

That's an excellent and very sharp question! You're absolutely right that the fundamental logical hierarchy in GTD is "Project -> Action." A project is the 'what' (the desired outcome), and an action is the 'how' (the next step). My point about reorganizing isn't about breaking that core logic, but about having the flexibility to change the layout and presentation of my lists to solve real-world friction as my system evolves.

Let me explain with my own journey, which I've shared here on the forums:

My "Before" State: The Classic Hierarchy

Initially, I followed the classic structure you described. I had my Projects list in one file, and a separate, flat gtd-next-actions.md file organized strictly by contexts (@Computer, @Home, etc.). This worked well for a while.

The Problem I Encountered

As my workload increased, this rigid layout started creating problems:

  1. The Project-Action Disconnect: When I looked at my giant @Computer list and saw a task like "Call the supplier," I had to mentally pause and recall which project it belonged to. The connection was purely in my head and easily broken.
  2. Loss of Focus: Seeing a long, mixed list of actions from a dozen different projects felt overwhelming and made it hard to build momentum on any single project.
The "Reorganization" I Made: From a Context-View to a Project-View

This is where the flexibility of a note-based system became a game-changer. I realized the view I needed wasn't a list of all computer tasks, but a view of what I needed to do for each project.

So, I reorganized the layout of my gtd-next-actions.md file. It's no longer a flat list sorted by context. Instead, it's now grouped by project, like this:

# @[[Project Alpha]]
- Call the supplier
- Draft the email to the team

# @[[Project Beta]]
- Research new software options

Why This Reorganization is So Useful:

This seemingly simple change in layout has had a massive impact:

  • Instant Context: Now, when I see "Call the supplier," it's nested directly under its parent project. The mental guesswork is gone.
  • Frictionless Workflow: Because I use Obsidian's [[Project Alpha]] backlinks, that title is a clickable link. I'm always just one click away from that project's "mission control" page, which holds all my reference notes and materials. The entire workflow is seamless.
  • Clarity and Momentum: I can now easily see all the active "fronts" for a single project, which helps me batch tasks and maintain momentum.
So, to summarize, you are 100% correct about the logical hierarchy. But the freedom to reorganize my view—from a context-centric list to a project-centric one—was a crucial step in making my GTD system truly work under pressure. A traditional task manager may have forced me to stick with its pre-defined structure, but a flexible tool like Obsidian allowed me to adapt the system to my needs, not the other way around.

Thanks for asking the question—it really gets to the heart of why this flexibility is so powerful:)
 
It’s interesting to see the # @[[Project Alpha]] syntax. I recognize the # as an H1 header and the [[link]] syntax, but what does the @ do? Is this the true project entry, or a generated list?

Also, I have to say that many apps today allow you to organize actions by project, with varying amounts of grace and style to be sure. It’s not unique to Obsidian by any means. But I’m glad someone is happy with it.
 
It’s interesting to see the # @[[Project Alpha]] syntax. I recognize the # as an H1 header and the [[link]] syntax, but what does the @ do? Is this the true project entry, or a generated list?

Also, I have to say that many apps today allow you to organize actions by project, with varying amounts of grace and style to be sure. It’s not unique to Obsidian by any means. But I’m glad someone is happy with it.
# as an H1 header and the [[link]] syntax —— This is correct.
The @ symbol mainly serves as a visual cue.
some Markdown renderings, the visual differences between H1, H2, and H3 headings are not very distinct. Adding @ can make it clearer to distinguish the names of main items.

Of course, some software can make these adjustments, but Obsidian is not limited to adjusting the style and location of tasks in units of "projects" or "@context". In fact, I can also format any project reference material or task into a table (and I can set what the rows and columns are respectively, and I can also add Mermaid diagrams or handwritten content from Excalidraw in it), or any other form. In a notebook software, this only depends on my ideas. However, in other task management software, there is not that much freedom. I think that as long as a task management software conforms to the user's habits, it must be more automated and easier to use than a note - taking software, but this depends on the adjustment or adaptation between personal habits and the software. Maybe one day I will also migrate to a task management software, but for now, there isn't a single one that can fully fit my constantly changing usage habits. After all, I'm still continuously exploring and improving on the path of GTD.
 
Last edited:
For me I can slice and dice my actions and projects in many more ways
The hierarchy is Project --> Action. How do you want to reorganize it?
I sometimes like to see things by project and sometimes by context. I like both detailed views and overall views. With a judicious and carefully curated set of "views" using the tasks plugin, some dataview queries on tags and some canvas documents I can easily flip between all different views. If one no longer serves me I can delete the note that create it and craft a new one. I am more in control. I know everything that is on my plate to do and I can breeze through reviews easily since I can group things in logical (to me) subsets for review.

For example: I have current projects where the next tasks require the excavator to be here at the main property. I can group projects by necessary requirements and during review I can ignore everything that is up here that requires the excavator since it's at a different property. Conversely I can look at all excavator tasks, and that can help me decide when we are going to move it to a new location. I can ignore all those sorts of projects entirely during review if the weather is bad because there is nothing I can do on them at all so why waste review time? There is ultimate flexibility in views that I never had before with a split system.
 
I have to say that many apps today allow you to organize actions by project,
For me it's not just by project or by context but any criteria I choose and I can do it on the fly easily and change those groupings quickly and with almost no friction. The new bases feature makes it even more powerful for on-the fly views of your overall system. The benefits of having the actions and the reference and supporting material in one place are huge for me.
 
For me it's not just by project or by context but any criteria I choose and I can do it on the fly easily and change those groupings quickly and with almost no friction. The new bases feature makes it even more powerful for on-the fly views of your overall system. The benefits of having the actions and the reference and supporting material in one place are huge for me.
@Oogiem Isn't it all about the data? I mean you can't organize or group anything if the items are not "organizable" – each item needs to have unique keywords or attributes to allow to group them "with almost no friction". It doesn't matter if you use Obsidian or Things.
 
@Oogiem Isn't it all about the data? I mean you can't organize or group anything if the items are not "organizable" – each item needs to have unique keywords or attributes to allow to group them "with almost no friction". It doesn't matter if you use Obsidian or Things.
That’s a great point, about data needing to be "organizable." But I think Obsidian fundamentally expands what "organizable" means, moving beyond the rigid need for explicit keywords or attributes that traditional task managers rely on. It supports Oogiem's view that you can group things by any criteria, on the fly, precisely because its organizational structure is so fluid and context-aware.

Let me illustrate with two recent examples of mine:

1.Handling Project-Specific vs. Miscellaneous Tasks:
You are right that organization is key. But in Obsidian, I'm not forced into one system. For a structured project, I can centralize all related tasks directly within that project's note, for example, inside [[Project Alpha]]. This keeps all tasks, notes, and reference materials for that specific project together.

However, for small, standalone tasks that don't belong to a larger project, I can simply place them in my daily note under a heading like # Miscellaneous Tasks. For instance, a task like ✅ Follow up on the refund for the returned item. By simply moving it to my daily note for today, the task automatically gains two powerful pieces of context without any extra effort: the completion date (the date of the note) and its category ("Miscellaneous Task"). I didn't need to add a completion_date: tag or a #misc tag; the context itself provides the data.

For those who don't use a daily note workflow, the principle of flexibility remains the same: you can just as easily create any other dedicated note—such as a "Miscellaneous Task Log"—to manage these items and their related reference materials all in one place.

2. Capturing Decisions Within Tasks:
Let’s say I have a task like: ☐ Finalize and document the installation details for the new office door. This task involves a discussion with a colleague to decide on its opening direction and precise location. In a typical task manager, I might check off the task and put the decision in a separate note, which could get lost.

In Obsidian, I can simply update the task itself upon completion:
✅ Finalize and document the installation details for the new office door - Decided on an inward swing, hinged on the left. [Link to meeting notes or daily log]
The decision—the crucial data—is captured directly with the task. It's searchable and permanently linked to the action. I didn't need a predefined "decision" field; the task description itself is a flexible container for this data.

So, to your point, it is all about the data. But Obsidian's strength is that it doesn't force data into predefined boxes. A task's location (in a project note vs. a daily note), its natural language description, and its connections to other notes all become rich, searchable metadata. This allows for the frictionless, on-the-fly reorganization Oogiem mentioned, creating a system that adapts to my evolving needs rather than forcing me to adapt to its limitations.
 
@Oogiem Isn't it all about the data? I mean you can't organize or group anything if the items are not "organizable" – each item needs to have unique keywords or attributes to allow to group them "with almost no friction". It doesn't matter if you use Obsidian or Things.
The crucial difference—and the reason Oogiem's workflow isn't replicable in a tool like Things—may lies in what those attributes are and how the system allows you to interact with them.

While both systems use "attributes," the nature of these attributes is fundamentally different.

1. The Nature of the Attribute: A Flat "Tag" vs. a Rich "Entity"

This is the most critical distinction.

  • In Things, when you add an attribute like a tag for Excavator, it's a flat label. It's a simple piece of text metadata that allows you to filter a list. The tag Excavator itself contains no further intelligence or information.
  • In Obsidian, the attribute would be a link, [[Excavator]]. This is not a flat label; it's a link to an entire note that functions as a rich entity. That [[Excavator]] note can contain its current physical location, its maintenance logs, when it was last refueled, or a link to its operating manual.
So when Oogiem reviews a task that requires the [[Excavator]], she's not just seeing a tag. She's one click away from a complete dashboard for that tool, enabling a far deeper level of planning and context. You can't do this in Things because its attributes are just labels, not gateways to more knowledge.

2. The Nature of the View: "Filtering a List" vs. "Building a Report"

Because the attributes are different, what you can do with them is also different.

  • Things has excellent filtering. It lets you narrow down a pre-existing list based on your tags. You are fundamentally reducing a master list to see a subset of it.
  • Obsidian, with plugins like Dataview, isn't just filtering. It's a query engine that lets you build entirely new reports from scratch, on the fly. Oogiem can create a dynamic table that GROUPS all tasks BY tool, or BY location. She can create a view that lists all tasks that require the [[Excavator]] but also have a due date in the next 7 days. This is about creating new perspectives, not just filtering one.
In summary, an analogy:

  • Things manages data like a spreadsheet with a great filter function. You have columns for Project, Tags, and Dates. You can filter to see only the rows you want, but the structure is fixed.
  • Obsidian manages data like a relational database. Every piece of information (a person, a project, a tool) can be its own "table" (a note), and you can use queries to create powerful, customized reports that join all this information together in ways the original creators never had to pre-define.
So, while you're absolutely right that it's all about "organizable data," the way Obsidian treats data—as deep, interconnected entities within a single, unified knowledge system—is what creates that frictionless, on-the-fly flexibility. It's a capability that dedicated task managers, by their very design and philosophy, cannot replicate.
 
Top