There are only certain tasks you can perform depending on where you are, when you are and what tools you have available. This is one of the core Getting Things Done principles that helps you focus on the tasks you actually can do instead of procrastinating over all the task you should or could do. At any given time I have approximately 700+ tasks in my OmniFocus and I could worry quite a bit when, if and how I could get them ever done. But I try not to instead I try to narrow down on those tasks at hand and contexts are what make this possible for me. Contexts are the first natural selection of tasks when you are in the ‘Do’ phase as they determine of what can be done.

Coming up with and maintaining contexts

However, it is very easy to over or under engineer the number of contexts you really need. Many implementations have far too many, others seem to ignore context altogether. The latter is fine when you are not into Getting Things Done, but then again you should use a more generic task manager instead of OmniFocus, which is clearly 100% GTD geared. There are three rules to help you define and, even more important, to maintain a reasonable and useful number of contexts.

Rule #1: Categorise your contexts

With very few exceptions the contexts I have seen and used myself in OmniFocus (or any GTD implementation) fall into three distinct categories. When sticking to those three categories you should also be able to determine exclusive definitions and hence don’t fall into the ‘I need to assign this action to multiple context’-trap, which some OmniFocus users have. The three categories are:

  • Places — Certain locations enable or allow you to do certain things. You can only pick up the office mail if you have access to your postbox or you can only paint the kids’ room wall if you are at home.
  • Tools — You need specific helpers at hand to complete an action. Be it your computer, a telephone, a broadband access or whatever tooling you need to do your job.
  • People — Following-up on something or talking about a topic is only possible if you are meeting an individual or a group of people. These are the famous ‘agenda’-contexts which provide you a list of topics to discuss with someone or to raise in a regular meeting. ‘Waiting For’ also falls into the people category since it is mostly individuals you need to do something for you, although in some occasions it might also be companies that you are waiting for.

Looking at my contexts, they all fall into these three categories, at least at the root level. Occasionally I have some contexts that I would called ‘activity’-focussed, but I’ll cover them later in this post

Rule #2: Don’t go over board

It’s relatively easy to end up having far too many contexts and this where most people go numb. While there is no best practice in terms of number, there are a few key principles that can help you determine whether you need a certain context in you list

  • Does this context typically carry more than two actions?
  • Is this a place/tool/person that I visit/use/meet regularly?
  • Is this context exclusive or is there overlap with others?
  • Am I going to granular? Could this action be assigned to a more generic context and it would still work? (see question one)

If you ask yourself these questions, and you can really just do it in a trial and error approach, you should be able to stick with a relative limited and static set of contexts. As said earlier there is no best practice in terms of number of contexts, but in most cases the levers are typically how much people you interact with and how many places you visit on a regular basis. These two factors may leave with you with a relative small or a hugh number of contexts. Depending on your job, people and places may also make your contexts more dynamic. If you do for example project based work (and many of us do this, I suppose), you may have different stakeholders and potentially new places with every new project. In this case you need to look at the third rule on a more frequent basis.

Rule #3: Review your contexts regularly

Reviews are the big mantra of Getting Things Done anyway, but every now and then you should also engage in a ‘meta review’. What I mean with this is a review of your productivity and task management system per se. What works and what doesn’t? I do this every six months, some (need to) do it more frequent some less. While this ‘meta review’ would be a separate post in itself, the one thing I also look at are my contexts. I am basically using the meta view to ask myself the questions I’ve listed under rule #2. Plus I also check if contexts which have a more temporary nature, e.g. a person I only work with on a specific project, are still relevant. Assigning actions to contexts This is a crucial part of your workflow and it’s often done the wrong way. Getting Things Done suggests two different stages when capturing a new action: The first is ‘Collect’ in which you should really just enter that thought or clip that email/website your are reading that, for whatever reason, has you attention. It will then happily sit in your OmniFocus Inbox and not yet move to specific context and project/list. While for actions that are clearly related to on-going projects and very obvious how they need to be performed you don’t need to think much, the second phase called ‘Process’ is actually extremely important to keep yourself sane and protected from collecting and committing to many activities. Only when you have time and process your inbox is when you can reflect on whether something really needs action, whether you need to do it yourself, if it is a single task or actually a new project and finally where, with whom or which tools in needs to be performed.

Pre-defining project contexts

OmniFocus offers the possibility to pre-assign a context to all actions in a specific project. It’s likely not the most frequent used feature of OmniFocus and hence I am not sure whether it is that useful, but here is how you define the default context for a particular project.

context-inspectorSelect the project and show the inspector (Menu > Inspectors > Show Inspectors or Cmd+Shift+I). Right under the Type and Status setting you can find a drop down in which you can select the default context of the project from you existing list of contexts. Any new action assigned to or created in this project will inherit this context automatically. You can certainly change the context for each action manually and any context you assign when creating or filing the action will not be overwritten by this setting.

Sample Contexts

This is the complete list of context I use on a day-to-day basis. Most of them are pretty static and usually have good number of actions assigned to. While I travel quite a bit and also get to work with a number of different individuals inside the large organisations I work with and for, there are typically not enough actions for those people and places to justify their own context.


places-contextsI have very few places I am at on a regular basis. For travel I use to have one separate context, but that didn’t really work for me since my actions are more tool or person related than to places and hence there hasn’t been much I could only do when in the train or plane. However, I do have a travel context in my errands section since there are a few things I like to buy in places where I travel to. Having a home and a corporate office there are a few, mainly repeating actions, I can only perform when in one of these places. Picking up the mail or shipping my expense report for example can only happen in my corporate office, scanning documents (into Evernote) or using one of my other computers is only happening in my home office. A trick I pull quiet often is to also assign actions to the root context (in this case ‘Office’). These are typically actions I can perform at more than one if not all sub-contexts. Printing a document for example can be done either in my home or my corporate office and hence I assign it to the ‘Office’ root context. Errands I run either online (kind of a virtual place), very often at Amazon and hence I made this a specific context, in the town I live in or the city I work in (if I am at my corporate office) or, as mentioned earlier, while travelling. If I would be more regular at certain shops, I would properly have s sub-context for them, but that isn’t really the case. All sub-contexts I had dropped out when I asked myself the questions of rule #2. Note that I use an iPhone App called ‘Groceries’ and hence the typical context of the supermarket isn’t in OmniFocus. Again if I can buy something either online or in a brick and mortar shop, I would assign it to the ‘Errands’ root level. If I need to buy something online, but not at Amazon, it would get assigned to the ‘Errands:Online’ context.


tools-contextsLike for most of us my main tool is my Macbook Pro. While I have a couple other Macs (all sitting in my home office), most things get done with the Macbook Pro. Lately things also can get done with the iPad. Since this is my main environment, I have broken it down in a few logical contexts. Like in the ‘Places’ context, I use the ‘Computer’ root context for anything that can either be done on the Macbook or the iPad. Things I can only do on the ‘iPad’, mainly because I need a specific, iPad-only App for them, are assigned to the ‘Computer:iPad’ context. My private expense tracking and financial budgeting is one example of such a iPad-only task. In the Computer category I also have one of these ‘activity’ contexts called ‘Computer:Read/Review’. I separated this context since I typically only engage in extensive reading or reviewing at specific times/energy levels and then batch read/review documents. Most of my daily or weekly review tasks are also assigned to this context. Using OmniFocus and Dropbox 99% of reading and reviewing can be done on either the iPad or the Macbook. Everything else really is covered by my ‘Computer:Macbook’ context which covers all tasks that require specific applications. I have seen people breaking it down to an application-level, but that is pure over-engineering for my and most people’s purposes. ‘Calls’ is an obvious context and since I have either my iPhone or my land line phone available, I can usually do calls at anytime. My ‘Online’ context is again broken down, mainly for the benefit of batch processing. Everything I need to do on the ‘Web‘ (in the browser) has it’s place (e.g. updating a wiki, uploading a document, posting to the blog), all ‘Email’ related tasks have their context (I read, process and respond to email typically twice a day) and ’Watch’ is a context that captures all the videos or web conference recordings I’d like or need to watch. One interesting context is the ‘Online:VPN’ one. This captures tasks which I need to perform using web-tools available in my organisations intranet, which I can only access through a VPN connection. That connection is automatically available to me when I am in either my home or my corporate office, but I could also establish it while being out and about. I still decided to create a separate context for it since it helps with batch processing and supports a number of my OmniFocus perspectives better.


people-contextsWhile I encounter different individuals, both on the customer side but also internally, I have a relative stable group of people I work with on a regular basis. This includes all individuals in the team I manage, my boss, a couple of peers in the same group and the sales team(s) we work with. For all of them I have an ‘Agendas’ context in which I file those topics I need to discuss with them next time around (often related to multiple different projects). Depending on the projects at hand, I may also have a temporary ‘Agendas’ context for a project with all relevant stakeholders below it. As seen before, I tend to use the grouping contexts like ‘Service Design Team’ or ‘Service Sales’ to file topics I need to raise with either that entire group, mainly at regular conference calls or meetings. Every Tuesday for example I have a 30 minutes call with my entire team for general catch up. Topics that need to be addressed as well as the standing agenda for this call are assigned to the ‘Service Design Team’ context. Topics that I need to address with other people, internal ones or customers, that aren’t explicitly listed get assigned to the ‘Agendas’ root context (you seen this before, haven’t you?). My misses, of course, has her very own context under ‘Agendas’. The kids are still to young to have their own context, but I can see that coming in a few years. Finally my ‘Waiting’ context more or less resemble my ‘Agendas’ context, but with a few individuals less. This is mainly due to the fact that most of the time I wait for people in my team or my manager to come back to me. Everyone else I am waiting for gets assigned to the ‘Waiting’ root context.


Contexts are an important part to any Getting Things Done implementation and OmniFocus offers great functionality in this domain. While contexts inside OmniFocus are mainly utilised in Perspectives, which I’ll cover in another post, it is important to come up with and maintain a reasonable number of useful and meaningful contexts. The three rules in this post should help, but ultimately you need to be comfortable with the contexts.