The Obsidian Tasks plugin is the right first choice for managing tasks in a vault, and for most people it is the only task plugin they will need to install. It turns plain Markdown checkboxes into real tasks with due dates, recurrence and six priority levels, and it lets you gather them from across the whole vault into live, filtered queries. Where it stops is instructive, and worth knowing before you build a system on it: it presents and sorts tasks beautifully, but it does not decide which of the tasks it surfaces you should actually do first. That last step, deciding, is a separate job, and a ranking layer like ZPXE exists to fill it on top of exactly this plugin.
This is a practical guide to what the Tasks plugin does, how its priority system really works, where its edges are, and how to combine it with the rest of the Obsidian task ecosystem without over-building. It sits inside the wider Obsidian task management stack, but the Tasks plugin is the piece almost every setup starts from.
What the Tasks plugin actually does
At its core, the plugin gives a Markdown checkbox a real identity. According to the plugin’s own documentation, you can attach due, scheduled, start and done dates, mark tasks with recurrence so completing one spawns the next occurrence, and toggle a task’s status from any query and have it update the source file. The querying is the headline feature: you write a small code block, and the plugin gathers every matching task from across the vault into one live list, grouped and sorted however you specify.
One setup detail trips up newcomers. The documentation notes that its screenshots assume a global filter such as #task, which is not enabled by default. Without a global filter, every checkbox in your vault is a task; with one, only lines carrying that tag count. Deciding this early matters, because it shapes whether your shopping-list checkboxes show up alongside your project tasks.
How the six priority levels work
Priority is where people expect the plugin to help them decide, so it is worth being exact about what it offers. The Tasks plugin supports six priority levels: highest, high, medium, a default of normal (no signifier), low, and lowest, each marked with its own emoji on the task line. You can then sort a query with sort by priority, and matching tasks come back in that order.
| Priority level | Signifier | Reserve it for |
|---|---|---|
| Highest | red marker | the one or two things that must happen today |
| High | double-up arrow | genuinely important, near-term work |
| Medium | single-up arrow | normal work that still matters |
| Normal | none | the default; most tasks live here |
| Low / lowest | down arrows | someday and nice-to-have items |
That is genuinely useful, but notice its shape: it is a manual label followed by a sort. You decide in advance that a task is high, and the query later groups your high tasks together. The plugin has no way to notice that a task you marked high three weeks ago now lives in a project you have abandoned, while a task you left at normal sits in the note you edit every morning. The label is static and your situation is not, which is the ceiling every manual-priority system hits and the reason a sorted list still leaves you choosing by eye.
Where the Tasks plugin stops
The plugin’s boundary is clean and worth naming, because misunderstanding it is what sends people plugin-shopping in frustration. It is superb at capture and presentation: writing tasks, dating them, and pulling them into filtered views. It does not do three things, by design. It does not rank on signals beyond the fields you enter, so it cannot factor in how central a task’s note is or how recently its project has been active. It does not decide, only sorts, so a “due today” query with forty results is forty decisions, not one. And it does not read the rest of your vault, treating each task as its text plus a few fields rather than as something embedded in a web of notes.
| Job | Tasks plugin | What fills the gap |
|---|---|---|
| Write and date tasks | yes, its core strength | nothing needed |
| Recurrence | yes | nothing needed |
| Query across the vault | yes, live filtered lists | nothing needed |
| Rank on context, not just fields | no | a deciding layer like ZPXE |
| Turn a long list into one decision | no, it sorts | a ranking that weighs many signals |
None of the gaps are flaws; they are simply outside what a query engine is for. The cost of the deciding gap is measurable: with attention already fragmenting, the American Psychological Association puts the price of switching between tasks at up to 40% of productive time, and a morning spent scanning a long sorted query to pick a starting point is exactly that switching, paid before work begins. ZPXE reads what the Tasks plugin already produces, its dates, priorities and tags, and adds the missing layer: it weighs those against signals the plugin never collects, link-graph centrality, recent activity, daily-note mentions, and returns one ranked list with a reason for each position. Because it reads the plugin’s own syntax rather than replacing it, the two compose cleanly.
Tasks plus Dataview, the common pairing
The other plugin you will hear about constantly is Dataview, and the relationship is worth getting right. Many people run both, and the Tasks documentation is direct about how they fit: Tasks owns task logic, Dataview owns general querying, and there is one sharp catch. Dataview does not understand recurring tasks, so completing a recurring task from a Dataview view records a done date without generating the next occurrence, quietly breaking the recurrence.
The practical rule that follows is simple. Use the Tasks plugin for anything involving task completion and recurrence, and reach for Dataview only when you want a dashboard the Tasks query language cannot build. The full trade-off is in Obsidian Tasks vs Dataview, but the short version is that they are complementary, not competitors, and routing completion through Dataview is the one mistake to avoid.
Getting started without over-building
The honest advice for a new setup is to start small and add only when a real need appears. Install the Tasks plugin, decide whether you want a global filter, and write a single query, tasks due on or before today, that you read each morning; the step-by-step is in how to use the Tasks plugin. That alone covers most people for a long time, and a setup you actually maintain beats an elaborate one you abandon. Add priorities when a flat due-date list stops being enough to order your day, and add Dataview only when you want reporting the Tasks language cannot express.
The moment to add a deciding layer is specific and worth waiting for: when your “due today” query regularly returns more tasks than you can rank in your head, and opening Obsidian produces hesitation rather than a clear first move. That hesitation, not a task count, is the signal that presentation is solved and deciding is now the bottleneck.
The mistakes that make people abandon it
Most complaints about the Tasks plugin trace back to a handful of avoidable setup mistakes rather than the plugin itself. The first is skipping the global-filter decision, then discovering weeks later that grocery-list and reading-progress checkboxes are mixed in with real tasks; decide the filter early. The second is over-using priority, marking so many tasks high that the sort groups nearly everything at the top and the signal is lost; keep the highest markers rare. The third is building an elaborate wall of queries before you have enough tasks to justify them, which produces an impressive setup you stop maintaining. And the fourth, if you also run Dataview, is completing recurring tasks from a Dataview view, which breaks the recurrence silently.
Each of these is easy to sidestep once named, and none is a reason to look for a different plugin. The Tasks plugin is not usually the problem when a setup fails; the setup is. Starting minimal, one query you read each morning, and extending only on a felt need, avoids all four and produces a system that survives contact with a busy week.
When the Tasks plugin is all you need
Plenty of people never need anything beyond it, and it would be dishonest to imply otherwise. If your vault is small, or you already know each morning what matters, the Tasks plugin’s queries are complete and free, and a ranking layer would be pure overhead. It is also enough when your work is externally scheduled, driven by meetings and deadlines someone else sets, because the prioritising is done for you and you only need a place to see what is due. The plugin earns its near-universal recommendation precisely because it is sufficient so often; the deciding layer is for the case where a large, self-directed backlog outgrows what a sorted query can resolve.
Key takeaways: getting the most from the Tasks plugin
Install the Tasks plugin first, because it is the mature, free foundation for tasks in Obsidian: real dates, recurrence, six priority levels, and live cross-vault queries. Understand that its priority system is a manual label plus a sort, which orders a list without deciding for you, and that its clean boundary is presentation, not judgement. Pair it with Dataview only for dashboards, and never complete recurring tasks from a Dataview view. Then, when a sorted query stops being enough to tell you where to start, add a deciding layer like ZPXE on top to rank what the plugin surfaces, with a visible reason for every task. Start simple, and add the next piece only when you feel its absence.
Quick answers
What does the Obsidian Tasks plugin do?
It turns plain Markdown checkboxes into real tasks with due, scheduled, start and done dates, recurrence, and six priority levels, then lets you gather them from across the vault into live, filtered queries you can group and sort. You can toggle a task done from any query and it updates the source note. It is the mature, free foundation most Obsidian task setups start from, excellent at capturing, dating and presenting tasks, though it sorts rather than decides.
How do priorities work in the Tasks plugin?
The plugin has six priority levels, highest, high, medium, normal, low and lowest, each set with an emoji signifier on the task line, and you sort a query with sort by priority to group them. It is a manual label followed by a sort: you tag a task’s importance in advance and the query orders by it. It cannot notice when a task’s real importance has shifted since you labelled it, which is the limit of any manual-priority system.
Do I need Dataview if I have the Tasks plugin?
Only for dashboards the Tasks query language cannot build. Tasks handles dates, recurrence and priority queries on its own. Dataview adds general querying across any vault field, useful for reporting, but it does not understand recurring tasks: completing one from a Dataview view records a done date without creating the next occurrence. Run both if you want custom dashboards, but keep task completion inside Tasks so recurrence stays intact.
Can the Tasks plugin tell me what to work on first?
Not really; it sorts, it does not decide. A query sorted by priority or due date gives you an ordered list, but ordering by one field is not the same as weighing which task actually matters most given your whole situation. For that you need a layer that reads signals the plugin does not collect, like how central a task’s note is or how active its project has been, and ranks on the combination. The Tasks plugin surfaces the candidates; a deciding layer chooses among them.
Is the Tasks plugin enough on its own?
For many people, yes. If your vault is small, you already know your priorities, or your work is scheduled by others, the Tasks plugin’s free queries cover you completely and a ranking layer would be overhead. It stops being enough when a due-today query regularly returns more tasks than you can rank by eye and choosing a starting point becomes the daily friction. That is the point, felt rather than counted, where a deciding layer earns its place on top.
