Flagged Projects - What's the advantage of the hollow flag?

When you flag a project, all of the actions are given a hollow flag. You can still highlight all of the actions and flag them, so the icon is not hollow anymore. What is the advantage/disadvantage of the hollow flag? Is it merely cosmetic to show that these are part of a project?

1 Like

Well, it’s more than cosmetic.

Tasks that belong to a flagged project are considered flagged, even if they’re not explicitly flagged themselves. Presenting a hollow flag makes it clear why, for example, they appear in a Flagged perspective even though they’re not flagged.


However the flagged project and the hollow flagged tasks are feed through the calendar feed and show up on the due date. If the only project is tagged then the hollow tags should not flow to the calendar feed.

The hollow flag is ridiculous. I flagged 3 projects to work on today and have 70 flagged items in the perspective. What??

This remains as the only problem that I have with OmniFocus. It seems illogical to me. I have 81 flagged tasks because I flagged the project!!

1 Like

You have my curiosity here. How would expect it to work?

So … Why flag the entire Project? That implicitly means, everything in the Project is flagged. Not illogical, just different from your desired approach.

Here are two ways around this.

Method 1 - Flag only the last step in the Project. The caveat is, the flagged task may not appear when something before it is limiting (i.e. in Flagged + First Available views).

My Last Step Project

  • first step …
  • complete the entire project <-- ONLY FLAG THIS

Method 2 - Flag only the first step in the Project and keep it flagged even as you do everything else. The caveat is, everything else might have to be in an Action Group or listed as parallel actions.

My First Step Project

  • start the entire project <-- ONLY FLAG THIS
  • first step
  • complete the last step

I use Method 2 in my weekly reviews. The notice (and only the notice) shows up in Due + Flagged views. I can go from there to flag tasks or action groups selectively.



Thank you. I really appreciate your writing this.

I have used a variation of this. In fact I set up a context “In Progress” so that I can highlight projects that are on my hot list. Bear in mind, I do not use OF as a project management tool so I have many 2-4 hour projects. So I created an “In Progress” perspective.
So if I am looking at this perspective, the In Progress list, and I want to focus on two of those projects this afternoon, I flag them from that perspective. This results in the over-flagging of the child tasks. I did not go into the project and it would be annoying to go into it and set up a start or finish task to flag.

Again I am baffled by what seems to me to be an easy preference to add to the app: “Flagging parent tasks flags child tasks.” -> Yes or No.

Flag to me means highlight. Not necessarily next action.

Please see below.

From what is happening it appears you have these projects set up as parallel projects. Can you set these projects as sequential? If so only the next action will show and all other flagged child actions are hidden, Then when the next action is checked off the next flagged next action will appear. I have several projects flagged like this and it works well and keeps my project flowing - as long as there is no need to have the project as parallel this is what you are looking for I believe.

From what I understand now, I have a different suggestion. Create another context, e.g. “Active”. When you pick a project to do, switch the context to Active rather than In Progress.

You are otherwise using a flag to indicate a change in status. The title of the Project is the recursive “super parent” of the entire set of tasks contained by it. So, logically, when you flag the “super parent”, you flag all of its “children”. By comparison, the context sticks only to the item itself … It does not propagate through the children.

You can fold the new context in to your Perspective (Project Overview) to see projects that are both active and in progress (or perhaps better said in this case “on deck”).


Thanks for the suggestion on contexts. I do not give every project a context, only those that I am most interested in. I could put others on “Hold” but then they are out of many of my perspectives. You are right about creating another context to highlight today’s projects as “Active” but this is not easy on the mobile app because there is no multi-select function on the iOS app. So, the flow is poor.

Again, a flag should be nothing but that, a flag and it should not flow to subtasks. What is the purpose of that at the task level? Sure, thematically you can make a case for it rolling down to the entire project, but there is no functional reason.

See this example: If I lay 10 strands of Christmas tree lights on the floor, all intermingled and mixed up like a plate of spaghetti (these are projects with subtasks) and I want to work on one of them (to check each bulb for being secure in its socket), I plug in a strand. The entire strand lights up (project parent and subtasks) and I can see how the light strand is interwoven among all of the other strands. But what good is that?? All I want to see at this initial moment is the plug and the first light, not the entire strand. And if I wanted to locate all other 9 first lights, it would be impossible to do at the same time because when I plug in all the other 9 strands I will end up with a spaghetti of light strands.

Do you see what I am saying?
This still seems like an easy preference to add to the application.

I see the issue with the ease on an iPhone. Flagging a set of Projects is faster than changing their contexts.

I see what you are saying.

I would suggest by experience, what seems easy to add and what will actually get added in a reasonable time are two different things. IOW, depending on your level of frustration and patience, you might want to consider the other options being proposed here.

In the meantime, feature requests need to be sent to Omnigroup via email.


This thread is interesting. I love that I can flag a project and have the tasks flagged as well. If there’s a project I need to work on for the entire day I can flag the project and have all of the tasks show up on my Dashboard (today list).

I can see the value of a preference but know that with development that would probably be a decent amount of work. Any new preference can usually add more complexity than you’d like.

My two cents about flagging projects. Disregard if under-caffeinated.

I get how GS6 was annoyed with so many tasks showing up because of flagging a project.

I work for/with the military and I assume this has some parallels with the civilian world as well. That is, we are working on projects and along comes an officer who wants their project to happen ASAP. So flagging the project, and it’s tasks, helps me out because they all show up in my perspectives.

If a project is super important, that is, it warrants constant attention and checking on, then I’ll make a perspective for it. Flags, for me, are like ‘due’ items without the ‘due date’, helping me keep true to when items are actually due. Using arbitrary due dates causes me to quit paying attention to the real due dates. I’ve also learned to not be scared to ‘unplug’ something.

I don’t show deferred or flagged in Forecast. I want only DUE there, to keep it clean, to get in and get out and see a bird’s eye view of the drop dead items this week.

Flagged items show up in a custom Today perspective. But what helps is that I’m a big user of the Serial task list, not parallel. If it is a 1/2 and 1/2 grouping, then I’ll make parent tasks as parallel and subtasks as serial. This keeps my perspectives clean with only the flags that I can work on at the moment.

Key in all of this is what David Allen refers to when he says that processing is different than collecting. I try not to get in and ‘fiddle’ with OF too much (and never getting anything done) but set aside a time where I review AND work on the nuts and bolts. That works well for me.