Task availability should be independent of context type

Currently in Omnifocus, a task with assigned on-hold context is, by definition, considered unavailable. That results in filtering redundancy: if you want to set context filter to ‘on-hold’, you also need to set availability filter ‘remaining’ in order to populate a perspective. What is worse, however, it is simply a waste in terms of potential filtering capabilities.

A real-world example using the most common on-hold type context: “Waiting”. In my “Waiting” perspective, I would like to be able to defer some of the tasks I’m waiting for. Although it is technically possible, there is no real gain as the deferred tasks do not disappear from the list. Why? Because deferred means unavailable and the task is already in this state because it’s been assigned the “Waiting” context.

Similarly, if one creates dependent tasks with pre-assigned “Waiting” contexts, all such tasks will clutter the list even though their predecessors have still not been completed.

Both cases could be avoided if availability was not taking context type into account. Then, it would be perfectly possible to create a perspective with the availability filter set to “available” and the context filter set to “on-hold” that would work as expected.

On the other hand, if one wanted to retain the current behaviour, he or she could simply filter by “remaining” tasks, exactly the same as required today. So nobody loses in such case.

Improving this functionality sounds like a 10-minute fix to me. I bet there is a dedicated function to determine if a task is available or not, hence all it would take is removing the context type from the equation. No back-end changes should be required to make it work. Unless I’m missing something here, I really wish it is not an awkward design choice but a simple omission that can be easily fixed in next releases.

1 Like

I am reviewing my OmniFocus setup, and am again confronting the challenge of Waiting For contexts being On Hold.

I like the concept of my Waiting For being On Hold, so they don’t appear in my tasks to do.

But the problem that surfaces, and always has me reverting to living with active Waiting contexts, is that all future Waiting tasks appear in the list. There is no way to show just the next (i.e. the blocking action) for each project.

I rely heavily on templates, and so I have a number of future actions within the template that are set to Waiting For. When I set Waiting For to On Hold, all of these appear in my perspective, and there seems no way to only show the next available Waiting For.

Has anybody found a good solution to this problem, or am I going to again have to revert back to Active Waiting For contexts?

My current workaround is to use an active “Will Wait” context for “Waiting For” that I want to defer. I combine it with a flag so that an action shows in my Today perspective once triggered, reminding me to switch it back to the on-hold mode.


A change I’d be happy with – and it seems not to add a lot of new baggage – is to make tasks On Hold with Flags appear in available/remaining lists.

This way I can make a waiting for task hidden (On Hold) and add a flag to defer it for when I want it to pop in my radar again.

Would something like this address your issues or not?