Delegated tasks?

[mattw]

How can I keep track of delegated tasks? I'm not talking about a someday/maybe list, but a list of active tasks that I am not completing, that something outside of me is depending on.

I tried to create a delegation system using contexts, but it is limited. I created an @Waiting context, and added @Joe as a subcontext under @Waiting. That way, anything that I'm waiting on from Joe will appear in that context. However, this does not work: OmniFocus does not know that actions with an @Joe context are out of my control and still will count them as next actions.

Are there plans on adding a delegation feature, or is there already one hidden away somewhere?

[bushford]

How to deal with delegation is one of the most contentious issues in GTD tools. I understand that Omni's view is that you should use contexts for this (@Joe etc) but I am not sure that it is an adequate solution. The context for a delegated action IMO is the place/time where you remind/chase/pester that person to complete the action.

The only tool that I have seen addressing this well is ThinkingRock. iGTD has it in its road map (in fact, the 1.4 released this week already allows you to filter for delegated actions, but you can't enter them :-)))

By the way, I think a delegated action can be the next action, if your own actions depend on it. Also, if you say that an action is completely out of your control, then it isn't really delegated, but you're just waiting for someting to happen. Delegation, as I understand it, means you ask someone to something for you, and the control you have is limited (you can chase), but it is real nevertheless.

Anyway, I have raised the delegation requirement on the Omni blog a while ago. Omni's view is, as I said, to use contexts. For some people this will be OK, but I'm not one of them.

(still waiting for the OF alpha...)

[SpiralOcean]

I'm not using OmniFocus yet, but let me see if I understand what you are trying to do.

You want a projects actions to be on hold, or invisible, because you are waiting for so and so to do something.

You can accomplish this with contexts.
You created a context for waiting for: Joe
Now you need to make your project sequential and make sure the task for joe is at the top of the list.

This will hide all other tasks until you check off the task associated with joe.

I'm assuming OmniFocus is allowing the sequential/parallel switch based on a task and not on an entire project. If this is true... here is how you would set up a project to automatically become parallel after the waiting for item is checked off:

- paint house: sequential
--call Joe about painting: waiting for
--Paint the house: parallel
---paint northside
---paint south side
---paint east side
---paint west side

once you have what you are waiting for from joe. the other 4 tasks should show up in their respective contexts.


Bushford:
I don't know where the contention comes in for contexts. If you have read Getting Things Done by David Allen, you will see that Allen has a context called waiting for. In the context he will put:
wf Joe to call me about tools
wf Susan to get materials

Contexts are not about place/time, but what tools you have avalible to you, which could include a place/time.
I am near a phone... go to the phone context
I am at the grocerystore... go to the grocerystore context
I have 10 min before my meeting starts and near a computer, what can I complete in 10 min.

Filtering for deligated actions is the same as filtering for deligated contexts.

[bushford]

I have read the good book, but I find in practice that waiting for as a context doesn't work for me, for delegated actions.

If I have a weekly meeting with Joe, then this meeting is for me the context for the delegated action. It is also the context where I have some actions for myself (e.g. "explain the planning for next month")

Susan, on the other hand, I never meet. I only talk to her on the phone. So that delegated action goes to the @Phone context.

The context information about an action is just not the same as the information about who has to do it.

So, I respectfully disagree.

I believe that David Allen is oversimplifying the treatment of delegated actions (am I a heretic now :) ?).

Particularly if 50% of the actions in my system are delegated, the context solution just doesn't fly for me.

[Ken Case]

I tried to create a delegation system using contexts, but it is limited. I created an @Waiting context, and added @Joe as a subcontext under @Waiting. That way, anything that I'm waiting on from Joe will appear in that context. However, this does not work: OmniFocus does not know that actions with an @Joe context are out of my control and still will count them as next actions.

Select the @Joe context, pull up the Context inspector, and turn off "Allows next actions". Now you won't see any actions assigned to the @Joe context.

I should note that that's not how I tend to work, myself: instead, I put a task in my Agenda:Joe context (which does allow next actions) so that I can ask Joe about it the next time I see him (possibly with a future start date so I don't bug him prematurely). But just because that's how I do it doesn't mean it's how you should!

[bushford]

Hi Ken,

I have tried that approach in kGTD for a while, but I kept finding myself scanning these Agenda:Joe "contexts" all the time while I was actually in another context (@Phone, @email, @developersmeeting). Not exactly efficient in GTD terms.

Anyway, as soon as I get a chance to try out OF I'll see what can be done and if there's another creative way of applying the context concept.

I admit I would be disappointed not to have any structural support in OF for delegation. ThinkingRock has the feature, and iGTD has it in the pipeline...

OK, I shouldn't tease :-)

[mattw]

I guess, for me, the problem really lies in OmniFocus's filtering mechanism. When I click on my @Joe context, I want to see ALL tasks under that context by default, since it is a "special" (for me) context ("Waiting for", "Agenda", what have you)

To solve this, OmniFocus should either remember the filters you apply on a context-by-context basis, or allow you to apply a default filter for a context. In other words, I know that every time I click on @Joe, I want to see ALL tasks, nut just available ones or next actions. Why should I have to configure this every time, when otherwise I just want to see available tasks or next actions?

[Hoff]

Hmm... In strict GTD, this situation sounds like you have 2 tasks: 1) Joe paints the house (in @Waiting), 2) Remind Joe to paint the house (in whatever context you would apply to the next time you want to contact him). One task for Joe, one task for you.

That's all in Focus right now.

It seems that some of this could be automated. Perhaps Focus could recognize @Waiting (or whatever) as delegated tasks and automatically prompt for a reminder or follow-up task? Perhaps you could attach multiple contexts to a task?

I can see this stuff being helpful, but also possibly as unnecessary additions to the UI. Above all, I think this thing needs to be simple, simple, simple.

[bushford]

Hmm... To keep it simple, when you delegate something, there should be only one thing you have to enter in OF, not 1) Joe paints the house 2) Remind Joe to paint the house. That's a reason why I think there should be specific functionality for delegated tasks.

Delegated stuff is not simply "waiting for": we wait for things over which we have no control (the weather, a parcel arriving by post, ...) but when we delegate, we still control and chase...

[lshastings]

I have read the good book, but I find in practice that waiting for as a context doesn't work for me, for delegated actions.

If I have a weekly meeting with Joe, then this meeting is for me the context for the delegated action. It is also the context where I have some actions for myself (e.g. "explain the planning for next month")

Susan, on the other hand, I never meet. I only talk to her on the phone. So that delegated action goes to the @Phone context.

The context information about an action is just not the same as the information about who has to do it.

So, I respectfully disagree.

I believe that David Allen is oversimplifying the treatment of delegated actions (am I a heretic now :) ?).

Particularly if 50% of the actions in my system are delegated, the context solution just doesn't fly for me.

It seems that some tasks may have multiple contexts, depending on one's view or perspective at the time. For instance one could put the delegated task for Susan in @Phone and @Agenda:Susan and @Waiting For. Not multiple tasks, but multiple views of the same task from different contexts. Modification or completion of the task in any one context is reflected in the other contexts.

Does OmniFocus support multiple contexts in this way?

[SpiralOcean]

Hmm... To keep it simple, when you delegate something, there should be only one thing you have to enter in OF, not 1) Joe paints the house 2) Remind Joe to paint the house. That's a reason why I think there should be specific functionality for delegated tasks.

Delegated stuff is not simply "waiting for": we wait for things over which we have no control (the weather, a parcel arriving by post, ...) but when we delegate, we still control and chase...

I disagree partially...

Delegated stuff involves both waiting for, and a reminder that if something hasn't been done in a given time, that you take another action.

You are waiting for a response from Vendor A about the email you sent.
If it hasn't happened within a week, you have another task to email the client to check on the status.

[maverator]

It seems that some tasks may have multiple contexts, depending on one's view or perspective at the time. For instance one could put the delegated task for Susan in @Phone and @Agenda:Susan and @Waiting For. Not multiple tasks, but multiple views of the same task from different contexts. Modification or completion of the task in any one context is reflected in the other contexts.

Does OmniFocus support multiple contexts in this way?

I just wanted to add my 2 cents into this - multiple contexts is a fact of life, and not just hierarchical contexts. I don't know how you deal with this from a visual standpoint in the context view, but the usefulness of OmniFocus (which otherwise looks incredibly useful) would be severely limited without multiple contexts. Simple example: @Shopping:Gifts:Mary and @Yardwork:Hedges:Mary. Maybe this is related to delegation, but in neither case is Mary actually doing the tasks.

[curt.clifton]

I just wanted to add my 2 cents into this - multiple contexts is a fact of life, and not just hierarchical contexts. I don't know how you deal with this from a visual standpoint in the context view, but the usefulness of OmniFocus (which otherwise looks incredibly useful) would be severely limited without multiple contexts. Simple example: @Shopping:Gifts:Mary and @Yardwork:Hedges:Mary. Maybe this is related to delegation, but in neither case is Mary actually doing the tasks.

I don't think I understand your example. Contexts in the GtD sense are particular places or tools that are preconditions for working on a task. I can see Shopping, Yardwork, and Mary all being contexts. I can also see Hedges being a context if there are lots of tasks that you do around the hedges. I don't see how Gifts is a context. It is a nice piece of meta-data to have available. I do like to search for gifts that I've given in the past to avoid buying someone the "perfect gift" two years in a row. :-) Omni is planning on including a meta-data facility for tracking such things.

I deal with multiple contexts by grouping contexts into places. For example, when I'm at my office, I want to see all the next actions in the following contexts: @Briefcase, @Computer, @On-line, @Phone, and @Agenda (the last having subcontexts for the various people I work with). On the other hand, when I'm on a plane I want to see @Briefcase and @Computer.

Considering lshasting's example about a delegated task to Susan being in @Waiting, @Agenda:Susan, and @Phone, it seems unusual to me for the item to be in all those contexts. If I just delegated something to Susan, then I'm waiting for it. I don't want it showing up on my agenda or phone contexts, lest it make me (even more) impatient. I would instead put the task in @Waiting with a due date. When the date comes up, I would reevaluate whether to send a follow-up (moving the task to @Email or @Phone) or to just put it on my agenda for the next time I see Susan. I also have to review my agenda items occasionally to be sure nothing is languishing there. To me GTD works best when I'm studious with reviews so that my context-based task lists are unpolluted by things I am not ready to do. If a task for Susan was immediately on my @Phone list right after I delegated it, then this would seem like task list pollution to me.

I'm not trying to say that multiple contexts wouldn't be useful, just that I don't understand yet how they would be useful. I would appreciate more examples, or perhaps just more description around the current examples. Maybe I'm missing the boat on something that would help me be more productive.

Thanks!

[SpiralOcean]

Contexts are not only places available, but tools available.
Example:
Computer
Internet
Those are two contexts that use the same tool, but one context could be used only where you have a computer and an internet connection, primarily the internet connection. The other context can only be used when you have a computer.

Gifts begins to seem outside context, unless it is around Christmas time and you want to see all the gifts you need to get for different people. Personally, I have a different program for lists like gifts.

The Susan being in @Waiting, @Agenda:

[maverator]

I don't think I understand your example. Contexts in the GtD sense are particular places or tools that are preconditions for working on a task.


I am not familiar with GTD, but I do have a concept of what's important for me to be able to keep my head wrapped around all the things that are important to me in my life. If you superimpose this idea on the contexts concept that GTD apparently has, which seems to be more pragmatic from your description, then that's where I'm coming from.

Here's an example. If I need to buy a gift for my friend's birthday, then the contexts would be "Personal" (because my personal relationships are an important aspect of my life), "Shopping" (more of a standard to-do type of GTD context category I guess), and "Finances" (because I would like to see a slice through all the items that are going to have an impact on my bank account). These categories don't have a hierarchical relationship with each other.

It's kind of like keywords or tags I guess, but with an application like OmniFocus I am hoping that visualization of tasks with respect to tags (contexts) is more explicit than it is with things like del.icio.us, where items are highlighted and the tags are listed in a subordinate way. One function of OmniFocus seems to be to view the contexts with the tasks subordinate (which is why I am drawn to it). As I alluded to in my last post, I guess the challenge with non-hierarchical contexts would be to find some way to execute this view so that tasks aren't duplicated on the page (or if they are, that there is some intuitive way to realize they are duplicates).

[LizPf]

I'm seeing a lot of people who don't know anything about GTD working with the OF alpha. And that's fine.

But it is a little like having a lot of people who don't drive evaluating cars. Yes, there are tons of things they can test out and judge as well as any driver (poor placement of window controls, too many cup holders) -- but there are things they shouldn't have opinions about because they can't drive. [why are both pedals operated by the right foot? would a joystick be better than a steering wheel?]

I'm not focusing on anyone here (especially the previous posters on this thread), but I've seen a lot of people question/complain about things that are addressed in the basic GTD literature. People are asking for built-in calendars, priority indicators and the like -- and these are not part of the GTD project list concept.

OmniFocus was designed to be a GTD Next Action manager. It was never intended to be a "do everything" personal life manager. It is a second generation product, Kinkless GTD was first generation. If you've never looked at KGTD, wander over to Kinkless.com and take a look. Ethan isn't working on this any more, but I think the old forums are still around.

Again, I'm not trying to single out anyone, just remark about a general attitude I've seen here.

--Liz

[BwanaZulia]

For GTD newbies....

Remember that Contexts are not "how you know someone or something" but at state of which you will be in that can do tasks.

Example: Gifts for my wife are not @Wife but @Errands since I am not @Wife doing tasks but I am @Errands around town and need to look at my list of things to do.

Example 2: When I need to discuss something with my boss it is not @Work but more @Agenda-Boss which means when I am sitting in a room with him I can bring up my @Agenda-Boss list and go for it as opposed to @Work which would contain a ton of other things.

Really though, OmniFocus, while not a 100% GTD application was built off of the idea of a PURE GTD app in kGTD and helped along by two people (Ethan and Merlin) who are VERY GTD.

You don't have to know all of it to use OmniFocus but it will help.

BZ

[ethan]

TO OMNIFOCUS DEVELOPERS...

I want to add a strong vote for MULTIPLE CONTEXTS... I know it is not a strict implementation for GTD but that truly cannot be the point. Omnifocus admits they are not simply an GTD tool.... I want to be able to put (for example) something in @Calls (where in true GTD fasdhion I list all my calls) but also in @LosAngeles so I can see the call as part of the actions I need to complete in Los Angeles. A VERY useful feature, otherwise I have to continually scan all my actions to make certain I haven't missed something....

[omnibob]

This may not be appealing or what you're after, but I'm experimenting with preceding any waiting for actions with "WF: ", and then filtering for that when I want to see those.

Bob

[geoffmb]

I'm seeing a lot of people who don't know anything about GTD working with the OF alpha. And that's fine....

But it is a little like having a lot of people who don't drive evaluating cars.

OmniFocus was designed to be a GTD Next Action manager. It was never intended to be a "do everything" personal life manager.

--Liz

Can we get someone from Omni to weigh in on this statement? If OF will only ever be a "GTD Next Action Manager" and not a (hopefully more flexible) personal productivity app, then it will probably save a lot of discussion (and more than likely push many folks back over to iGTD).

-gb

[Lizard]

While OmniFocus was inspired by kGTD, we do hope that it will also be useful by people who don't follow strict GTD, or even very much of it at all. So go ahead and send us requests (ideally via email) for things that don't necessarily fit within "strict GTD". Where GTD and other approaches are in absolute direct conflict, we will probably choose in favor of the GTD approach, but when both can exist in harmony (or be toggled with a checkbox in the preferences pane), we'll try to please everyone.

[geoffmb]

Great to hear! Thanks.

Now about multiple contexts...

-g

[sprugman]

I'd like to put my vote in favor of either mutlple contexts or, preferably, multiple inheritance in contexts (like Places in Life Balance). Since I work at a computer from home, traditional GTD contexts aren't that useful to me, but I still very much need to be able to filter a long task list down to a scanable number of tasks (10-20).

With LifeBalance (who's interface I despise), I found it useful to create places like this:

Clients
--- JPM
--- --- JPM Next
--- --- JPM Soon
--- Dante
--- --- Dante Next
--- --- Dante Soon
--- Toews
--- --- Toews Next
--- --- Toews Soon

Next
--- JPM Next
--- Dante Next
--- Toews Next

Soon
--- JPM Soon
--- Dante Soon
--- Toews Soon

---------------------------------

I used the Next and Soon places to say roughly "today" and "this week" as I was doing my reviews. The nice thing about this set up is that I could easily see what was going on with a particular client, or all of them, OR what was going on today and this week. I'm sure there are ways to achieve this with focusing/filtering, but jiggering around those controls all the time is not fun. Perhaps once perspectives are working well, I'll feel differently.

(dupe of feedback message)

[SpiralOcean]

I used the Next and Soon places to say roughly "today" and "this week" as I was doing my reviews. The nice thing about this set up is that I could easily see what was going on with a particular client, or all of them, OR what was going on today and this week. I'm sure there are ways to achieve this with focusing/filtering, but jiggering around those controls all the time is not fun. Perhaps once perspectives are working well, I'll feel differently.

(dupe of feedback message)

I was a long time Life Balance user as well.

Your example is a merit of LB's method of context inclusion.
But your example is what you had to do to work around LB's shortcomings.

It sounds like you may be resisting OF. You may be resisting learning a new way of using a tool.

With your examples, it appears to me that OF covers most of your LB workarounds.

You are correct, the groupings do need fiddling, but in regards to the amount of workarounds you had to do in LB... it is easier in OF. It's like a great weight has been lifted from my chest in my conversion from LB to OF.

My sense is you had to create workarounds in LB, and your mind had to create new pathways to work in that application. You don't know if you can trust OF's way of doing things, or are just resisting doing it a different way because of the herculean effort you put into LB.

What would you think about posting a specific example of something you are attempting to do?

[jasong]

I want to be able to put (for example) something in @Calls (where in true GTD fasdhion I list all my calls) but also in @LosAngeles so I can see the call as part of the actions I need to complete in Los Angeles

Hi Ethan,

I had a similar need as I was getting to know getting things done. I had a "calls" context for "personal" and one for "work". OmniFocus will actually accommodate this, depending on how you want to see them. You can either have

@Calls
--@Los Angeles
--@Boston
--@New York

which, if you select "@Calls" will show you *all* the calls you need to make, and if you choose @Los Angeles will show you *only* the calls you can make while in LA.

Or you can have

@Los Angeles
--@Calls
--@Errands

which lets you see everything you need to do in LA, or only the calls you need make while in LA.

Here's what I do now, though. Instead of using Contexts for this, I use folders. I'd have an LA folder which contained all my projects I can only do while in LA. When I want to see what can I/do I need to do in LA, I double-click the LA folder (or choose View > Focus on selected project), and voila! my list of actions is instantly limited.

I now have a single Calls context, and if I'm at work, I simply double-click my Work folder and there are my calls for work, unpolluted with my personal calls.

[sprugman]

The thing that I don't like about the folder approach is the number of steps it takes to change views.

1. go to project view
2. unfocus
3. find folder I'm interested in (which could take some clicking)
4. focus
5. go back to context view

That's fine if you're only changing folders a few times a day. I'd like to be able to be more dynamic than that, and to easily compare/choose between various folders. Robust Perspectives will probably help this when they come. And clearly, I'm still working on my structure/strategy for OF (as are we all)....

[Leonardo]

Hi Ethan,

I had a similar need as I was getting to know getting things done. (…)
You can either have

@Calls
--@Los Angeles
--@Boston
--@New York

(…)

Or you can have

@Los Angeles
--@Calls
--@Errands

(…)



You do not take into account that your choices are exclusive:
subdividing calls in your example would lead to a fragmented @Los Angeles context.
If I am at Los Angeles and want to go through my list of next actions for Los Angeles
I would have to look up @Calls - Los Angeles, @Errands - Los Angeles, etc.
If taking your second choice and I am in my office and want to check off some due calls
I would have to go through @Calls, @Los Angeles - calls, etc.

GTD is about being ready to perform and the basic premise is getting things off your head
in order to be present and focussed on the immediate task at hand.
Creating hughe hierarchies is uneffective and counterproductive.
Ethan's suggestion of multiple contexts is trying to keep things simple.

[al_f]

If I am at Los Angeles and want to go through my list of next actions for Los Angeles
I would have to look up @Calls - Los Angeles, @Errands - Los Angeles, etc.
If taking your second choice and I am in my office and want to check off some due calls
I would have to go through @Calls, @Los Angeles - calls, etc.

IMHO a better way to handle that would be to put calls you can only make in LA into a @LA context as "Call Bill about account" or whatever, leaving @calls for those calls you can make any time you have access to a 'phone. similarly, if it's an errand you can only do in LA put it in @LA as "Buy fish" or whatever, then keep @errands for errands you can run anywhere.

For me the key to deciding what context you put something in is "what can I absolutely not do without to perform this task". If you make that decision you don't really need to put anything into more than one context.

[jasong]

You do not take into account that your choices are exclusive:
subdividing calls in your example would lead to a fragmented @Los Angeles context.
If I am at Los Angeles and want to go through my list of next actions for Los Angeles
I would have to look up @Calls - Los Angeles, @Errands - Los Angeles, etc.
If taking your second choice and I am in my office and want to check off some due calls
I would have to go through @Calls, @Los Angeles - calls, etc.

Absolutely right, which is why I no longer use contexts in this way. I have a single Calls context. Much easier for me to deal with. The stuff I can do in LA are part of projects, and I focus in on those LA projects and see only the LA calls.

Jason.

[jasong]

IMHO a better way to handle that would be to put calls you can only make in LA into a @LA context as "Call Bill about account" or whatever, leaving @calls for those calls you can make any time you have access to a 'phone. similarly, if it's an errand you can only do in LA put it in @LA as "Buy fish" or whatever, then keep @errands for errands you can run anywhere.

That pollutes your contexts, doesn't it?

You find yourself sitting in traffic (hey, it's LA, right?), and you look up your @LA context, and you see "Buy fish". Hm. Not very actionable right now. It's just reminding me of something I can't do. Not good.

But if you lookup @LA Calls, see "call Bill...", well, you pull out that iPhone, stick a headset in your ear, and you're off.

Jason.

[wheeles]

I was wondering what to do with actions or projects where I am currently waiting on something for the next step to be possible. On reading this thread it became clear to me that it isn't necessarily multiple contexts that are required, but instead an additional status setting of Waiting For.

The way I see this working is that when you set the status of a project to Waiting For, then you can also set a reminder date when you chase this up if you are still waiting. OmniFocus could be configured to generate a Chase up action for that project on that date. OmniFocus could also have a little icon for the project like there is for On Hold projects, so you could see at a glance what actions are dependant on others and which are not.

It would also be useful to be able to add another option to the filtering of actions so you could view Next Actions including the list of Next Actions that have a status of Waiting For as well as the Next Actions and not display those projects where you are waiting (unless the chase up date had arrived).

Why not use On Hold, I hear you ask? Well, to me On Hold is for those projects that are in the Someday/Maybe category.

Of course, you could use On Hold instead of Waiting For, but then I would want a Someday/Maybe status instead to distinguish the two.

[SpiralOcean]

I was wondering what to do with actions or projects where I am currently waiting on something for the next step to be possible. On reading this thread it became clear to me that it isn't necessarily multiple contexts that are required, but instead an additional status setting of Waiting For.

The way I see this working is that when you set the status of a project to Waiting For, then you can also set a reminder date when you chase this up if you are still waiting. OmniFocus could be configured to generate a Chase up action for that project on that date. OmniFocus could also have a little icon for the project like there is for On Hold projects, so you could see at a glance what actions are dependant on others and which are not.

It would also be useful to be able to add another option to the filtering of actions so you could view Next Actions including the list of Next Actions that have a status of Waiting For as well as the Next Actions and not display those projects where you are waiting (unless the chase up date had arrived).

Why not use On Hold, I hear you ask? Well, to me On Hold is for those projects that are in the Someday/Maybe category.

Of course, you could use On Hold instead of Waiting For, but then I would want a Someday/Maybe status instead to distinguish the two.

Now that we are careening... :-)

I leave the due date filter on at all times. For waiting for items, I will set a due date for the action.

Every day I look at my waiting for items.
Those in the today grouping, I review:
If the item is complete, I check off...
If I need to do an action... I'll do the action... or put it in my system
If I want to wait longer for it... I'll tab over and change the due date.

Waiting for Items are an anomoly.

I am constantly using the 'show in project view' menu command (can't wait for that one to be fixed) to go to the project of the waiting for item to enter the next task.

For example:
call Apple to inquire about my free iPhone - calls

So I am going through my calls. I make the call to apple and leave a message.

I need to have a waiting for item in that project.
select show action in project view
enter task... waiting for return call from apple-waiting for-due on friday
set it as a child of the call action listed above

On friday, I am reviewing my waiting for items
I see that apple hasn't called back yet.
I complete the waiting for return call from apple
the
call Apple to inquire about my free iPhone-call
appears in the calls context

When I do my calls, I leave a voicemail at Apple
And now I go and enter another waiting for item.

[brianogilvie]

So I am going through my calls. I make the call to apple and leave a message.

I need to have a waiting for item in that project.
select show action in project view
enter task... waiting for return call from apple-waiting for-due on friday
set it as a child of the call action listed above

On friday, I am reviewing my waiting for items
I see that apple hasn't called back yet.
I complete the waiting for return call from apple
the
call Apple to inquire about my free iPhone-call
appears in the calls context

That's a great idea! It will be wonderful when it actually works. Right now it doesn't, though, at least not for me. When I complete a subaction, its parent does not show up as available.

As a workaround, though, until the bug is fixed, I can simply delete the "waiting for" subaction, at which point the parent will show up as available.

[iancjclarke]

I'd like to put my vote in favor of either mutlple contexts


Just want to weigh in and say that I also found myself missing this ability, the hierarchical approach to contexts just doesn't cut it. If contexts are prerequisites for performing a task, then isn't it reasonable that some tasks may have more than one prerequisite?

[curt.clifton]

Just want to weigh in and say that I also found myself missing this ability, the hierarchical approach to contexts just doesn't cut it. If contexts are prerequisites for performing a task, then isn't it reasonable that some tasks may have more than one prerequisite?

Perhaps you just misspoke, but that is the opposite of what people are asking for in this thread. If a task had more than one prerequisite, than they would all have to be satisfied before the task was available. Multiple contexts as discussed here are for actions that could be done in any one of a number of contexts. So the conversation with Susan could happen in an @Call context or in an @Agenda:Susan context.

[carey262]

It would be awesome if you could create a task and assign it to a person. Then this person would receive an email detailing the delegated task, and if they had an omni account registered to their email (and you had permission to delegate to them) that the task automatically appear as a delegated task in their own copy of Omnifocus.

Then, when they complete the task, you would be abel to see that they had marked the task as completed in your own copy of OF (in the delegated status area), at which point you could then mark it as completed on your own list.

Do this, OMNI, and you will dominate the world with your to-do-list system.