Help with status of "Waiting" context

Hi,

I am new to OmniFocus and am a little confused about the status for contexts, especially the “Waiting” context (I think it is in-built) which has a status of “On Hold”.

  1. I expected that clicking on Contexts > Waiting would list all projects that have their status set to “On Hold”. However, the context seems to only list items whose context is set to “Waiting”. Is this behaviour normal? Is there a way to see all items that have the status “On Hold”?

  2. When I assign the context “Waiting” to a project or action, it does not change its status to “On Hold” even though the status for the context has been set to “On Hold”. However, actions with the “Waiting” context do behave like “On Hold” items, in that they do not show up in the Available view. In effect, actions with a listed status of “Active” behave like “On Hold” actions. I find this quite confusing! Shouldn’t their status change based on that of their context?

I’d gladly welcome some help in understanding the issue better. Many thanks!

1 Like

Hi @Anjadekar! Welcome to OmniFocus. I’ll try to tackle your questions in order.

  1. In OmniFocus, contexts are their own containers. They can hold actions, or other contexts, but they aren’t “filters” for the rest of your database. In that sense, Waiting is just another context – when you click it, you see the things assigned to Waiting, but it doesn’t search across the entire database for other on-hold items.

    If you have OmniFocus Pro, you can set up a custom perspective to show projects that are on hold. Take a look at the Perspectives setting of the user manual for more details on this.

  2. Items – both projects and actions – have their own status, and assigning an item to a context doesn’t change that status. However, what you’re seeing is a change in the availability of that item. The availability is an aggregate of all the different metadata on a particular action; in this case, items that are in an on-hold project or an on-hold context are considered on hold, and thus not yet “available.”

    This might be easier explained through example. Let’s say I have a project named “Paint the living room.” I assign this project the Home context, because I’m doing most of its actions at home. The project and its tasks are available. Then I decide that I don’t want to paint yet. It’s not quite right to assign the project to the Waiting context – that would erase the fact that I’m doing it at home – but I don’t want it to be available. This is where I can put the whole project on hold; it and its tasks are now unavailable, and will show up in fewer places in the app.

    By contrast, let’s say I have an important secret project at work called “Ship feature X.” This project is also active (and therefore available), but I need feedback from a teammate on one particular item. I can make a task – something like “Wait to hear from Rebecca” – and assign it the Waiting context. This task isn’t actionable by me, so putting it in the Waiting context makes it unavailable. When I hear back, I can check it off and proceed with the rest of the project.

Does that help clarify?

5 Likes

Hi @tekl! Thanks for the comprehensive explanation. It’s clear as day now!

2 Likes