Todoist filters: verify a query with known matching and excluded tasks

SOURCE-BASED ANALYSIS · NO HANDS-ON RATING

Start with expected results

A filter is a saved view, so a plausible-looking list does not establish that the query is right. Todoist documents AND as &, OR as |, NOT as !, and parentheses for grouping. It also warns that filters referencing a renamed project need manual updating. Keep the expected task set beside the query.

A five-task example

Suppose your intended queue is work-project tasks that are either due today or overdue. Create five synthetic tasks: Work today, Work overdue, Work next week, Home today and Home overdue. The target list contains the first two only. The documented expression (today | overdue) & #Work expresses that intent when the project is named Work.

The future Work task tests the date boundary; both Home tasks test project scope. Without those deliberately excluded examples, a broad query could appear to work merely because the account currently contains no conflicting tasks.

Debug one condition at a time

1. Open the project and verify that the fixtures have the intended dates.
2. Check the project selector alone, then the date expression alone.
3. Combine them with explicit parentheses.
4. Compare actual membership with the five-row expected list.
5. Rename a rehearsal project only if you need to validate your rename procedure, then update its query references.

Understand a view's limits

Todoist says ordinary filters show active tasks and cannot inspect comment contents. A missing completed item or a word found only in a comment therefore calls for a different retrieval method. Do not keep adding Boolean operators to compensate for data that the filter does not search.

Record why each boundary task belongs or does not belong. If the same query is used for a daily review, include a short description stating the purpose and owner. Recheck it when projects are renamed, the team changes labels or a task is moved to a different place.

Choose a useful failure signal

An empty list should mean that the defined queue is empty, not that nobody knows whether the filter still works. Keep one safe rehearsal example or a documented fixture recipe that can be recreated after a change. Remove synthetic tasks after validation so they do not pollute a real review. If the results still disagree, record the smallest failing query and task attributes before contacting support. This is a validation method; no account or platform-specific test result is claimed here.

For the complete learning path, visit the Todoist practical guide hub.