Project Review Settings

Sorry for what is likely going to be a very long post. I’ll try to get to my “ask” as quickly as I can. If you don’t want all the back story just jump to the last paragraph.

I’m a long time user of OmniFocus and even longer GTD practitioner. Many of friends and colleagues are as well. Many of us are moving into new positions within our corporation and it stirs discussion and debate on personal to-do tracking and general productivity. One recurring problem/theme is this issue of “falling off the bandwagon”. Those that I’ve discussed this issue with at length seem to all agree as to root cause. Many times it comes back to the efficiency of the system and it’s inability to keep up with what is an every increasingly fast paced world and our desire to make sure that “nothing slips through the cracks”. So recently I decided I really wanted to crack this problem for good as my life just feels out of control when I’m “off the bandwagon”.

To start, I went back and re-read Getting Things Done by David Allen from cover to cover. I also re-read Creating Flow with OmniFocus by Kourosh Dini. I then archived my entire OmniFocus database and started over. From scratch. Yes, you read that correctly…From Scratch. Every project, context and perspective (outside of the stock ones) were deleted, wiped clean or reset. I was already off the band wagon right? So not really much to lose. But it’s allowed me to look very closely at how a task or project makes it’s way through my system.

One of the revealing parts to this experiment was the identification that certain projects had no chance of getting tasks added to the “Today” perspective, because of flow. I know, your asking well why was that? I thought you said you’re a long time user OmniFocus, which somewhat implies being an über OmniFocus know it all? … yeah well bugger off! … Actually it has nothing to do with finding the magic combination of settings that generates the “one perspective to rule them all!”.

While I’d love to lock myself in my office and tinker with my raspberry pi until I’m sick/bored with it, the world doesn’t really work that way. We all have responsibilities. Those typically involve projects, which more often than not get grouped into folders representing those responsibilities. In order to make progress, one needs to review them on some “trusted schedule” such that we know the work will eventually hit that “Today” perspective. Now, I’m not sure about you but I’m pretty sure the number of projects in my OmniFocus database is near the 100-150 mark. And that brings me back to the weight of it. See a strictly pure “Weekly Review” of 150 some odd projects is simply daunting. Yes, not all of those need to be reviewed on a weekly basis. In fact, the realization that not every project should be reviewed that frequently has been one of the major changes I’ve implemented in my personal workflow. In fact, I’m starting to conclude that there are categorizations of responsibilities not necessarily projects that need to be reviewed on a periodic basis. To that end I’ve started giving each day of the week a “theme” in which categories of responsibilities/projects fall into and used that to determine when and at which frequency a project will get reviewed. Regardless of your mental approach to determining when a single project should be reviewed, I think the gang at Omni felt the same way with regard to having to review lots of projects in a single sitting when they created the “Next review” setting and reviewing perspective.

So like I mentioned, I’ve carefully made sure that projects whose “theme” is to appear the next day, magically appear in the review perspective today. I’ve included a task in my daily evening routine that directs me to the review perspective to make sure its cleaned out just like the inbox. Honestly, I was on roll and everything in my system was actually feeling pretty good. Then, I got sick. Like terribly sick. Like spending 4 days on my backside kind of sick. In that time, I kid you not, I had 50-60 projects come up for review. I was like ok, yup, I’m about to fall off again. But I told myself to suck it up buttercup, crank through these and then get on to do. About half way through I scrolled up to one of the previously reviewed ones. It’s set for Review Every 1 Week and is now showing its next review to be 7 days from today. Hmmm… So I scroll up to another with the same frequency. Up same deal. Then another, and another, and … well to my shock and horror I came to a new level of understanding of Omni’s interpretation of that setting. And actually, I get why it’s that way. I haven’t proven this to my self yet, but I think based on this, the system over time will become clumped, like a fragmented hard drive. In others words in about 7 days time I’m going to have 20-30 projects to review again, instead of the 5 or 6 that I should. Certainly all the care into my next review assignments is now wasted and I’ll have to go back and reset all that. But thats some serious friction in the system and can potentially lead to bandwagon issues. Which now brings me to my ask/question/feature request.

What I’d like to see is an additional option for handling how the next review date is generated. What I’d like to see is some of the project repeating options carried over to review timing. While not ideal, the repeat every as implemented in the repeating options for projects would actually solve my problem described above. I say not ideal as I’d fully expect to potentially mark a project reviewed multiple times before it cleared the review perspective. At the same time I see value in the current implementation and would have uses for it as well. Would that be possible and would other find that valuable?

Maybe you can start by saying no to many of these projects? Especially the Someday/Maybe (on hold) projects. The project might start out as a great idea but its relevance/importance fades over time. Sometimes sheer enthusiasm will spark project ideas and we save them. But not every idea is a great idea (or even a good one at that).

Maybe it’s a good time to reflect on core values and see which project(s) bring bang-for-the-buck or a great cost-benefit ratio? Eliminate anything that doesn’t align with your core values (or your company’s core values if you have to answer to the boss). Every month, I’ll ask my wife about a project idea and she’ll just nix it as irrelevant or no longer important. whew… that has saved me lots of times before starting out an a project my wife wants done (typically home renovations).

Most of my Someday/Maybe (On Hold) projects are set to a longer review cycle. These projects are set off into the way future and will have a longer review cycle. I don’t need to monitor it closely. I just have to get tickled every once in a while about a someday/maybe. Then I can determine whether to keep it on hold until the next review cycle, delegate it to someone else who has the talent/time/skills/energy required to finish this project, or just delete it. Some Someday/Maybe projects are set to one month, 3 months, 6 months, or 1 year review cycles.

Currently active projects are set anywhere from a 1 day review cycle to a 7 day review cycle. Projects that have to be monitored more closely or have constant changes will have a shorter review cycle.

Delegate as much as you can. Hire someone to complete the job that may be beyond our current skill level or time capacity.

Delete anything that doesn’t mean as much anymore.

Do all of your projects need to be reviewed on a constant or weekly basis?


I agree, with the original poster, some projects just do not need reviewing very often. I had quite a few projects that were basically a list of repeating tasks, pay X bill, check deployment server configs etc. These actually rarely needed “reviewing” maybe once every 3 months, and I set the review time accordingly.

Projects are not always about saying no, sometimes they are personal or just aide memoirs where no is not an option, certainly as a self employed developer “no” is a luxury I rarely have.

I can honestly say I have never read “Getting things done” it seems to inspire an almost religious fervour in some, personally I have taken a lot from here, from the web and made something of my own. Never been one to conform or tow the line, and I have been lucky that I have been able to indulge that luxury.

1 Like

I had a similar experience with OF in the beginning. Everything that looked important to me was saved within OF, and I ended up with about 50-70 projects and a lot of someday/maybe tasks etc.
The review process was horrible, I skipped a lot of projects or even skipped the review at all. Reviewing 30 projects on a single day is very time consuming! And what main benefits do you get after the review process when the main time of it includes looking on someday/maybe tasks or projects? Mostly it is not worth to waste your precious time with looking on someday/maybe actions on a frequent basis.

I knew that I had to start over again but I didn’t delete the whole database. What I did was copying the someday/maybe projects to a minmap. It’s very easy to structure those projects in a mindmap and as a consequence you get a good overview. So, a lot of projects disappeard from OF and a weekly tasks reminds me to open the mindmap and decide if I have time to start with another project and copy it back to OF.

However, there where still a lot of someday/maybe tasks and useful references such as links to blog articles, quotes, ideas etc to consider within OF. OF is no reference system. I didn’t believe it in the beginning and learned it by hard. Well, in some kinds it works great as a reference system (e.g. collecting information) . But when it comes to the daily/weekly review process, you should just look on projects that have already started and whose next tasks need to be a updated or modified. The fewer tasks/ projects the faster you can update/check everything.

The other thing is choosing the next actions for today. The smaller the available tasks list, the easier and faster you can decide what to do next. But especially, when you have a lot of projects within OF which are not paused results in many many tasks to choose.

So I copied all reference into EagleFiler and created tags which allows me to find all the information that I need. Well, it was not easy to set up but there exists a lot of articles regarding this.

After fixing all these struggles I have found out, that it is the best to focus on 2-3 main projects within a single week. I always decide the end of the week before which projects to focus on. These projects get assigned with a context with the highest priority 1-ImportantUrgent. All other projects have priority 2-Do or 3-Begin or are in a backburner context state (no context). But just projects which has an end date (e.g. get finished within the next few weeks/months) are assigned with such a priority and displayed within my Kanban board. I’m using omniboard for realising this. Projects like finance or house which are continous projects are not assigned with a context and also not within my omniboard. All in all I have about 10-15 projects plus additional 10-20 continous projects which never end.

I know that I didn’t answer your question but I hope that you find something useful which can help you along your way.

I empathize here as well. One ongoing struggle I have in OF is to address exactly the question “How often do I set a review for this Project”.

I have ended up for now using an Applescript to set review periods for me. The criteria are based on such questions as “Is this on hold or active?”, “Is it an @Admin project?”, “Does it have only one remaining action to complete it?”. I basically got tired of trying to decide for each project. I let the default at 3 days, then I adjust based on the AppleScript.

I run this Applescript periodically, for example when I think my review cycles are certain projects are getting a bit too “off kilter” or when I’ve gone through a long period of changing the status or completion items on projects.

Otherwise, my thoughts on why to do a review are this …

  • Do it to determine whether something about the project needs to be changed.
  • Do it to change the status of a project between active <-> on hold.
  • Do it to tidy up loose ends, for example to close out tasks that have been completed but not noted as such.
  • Do NOT do it as a way to figure out what to do now or next.

Also, I agree that some additional tweaks on review settings might be useful. I wonder though whether this gets too far in to over-analyzing the mechanics of a review and therefore over-designing the features associated with it.

Hope this provides some insights.



Curious to see your above mentioned AppleScript, @DrJJWMac ;-)



especially if you miss your review days your system is really undermining your motivation. i once had this problem too, especially if your review dates are deranging from your wished schedule, because you once made your weekly review few days to late.

What really helped me to stay on top is this Script from Joe Buhlig. It is existential for me to really use omnifocus successfully in the longterm.

Hope this will help you as well


What’s wrong with ignoring the built-in reviews and rely instead on a ‘review’ action that adds a new instance of itself some number of days after the time it was marked complete?

My daily review can be overdue by however many days, but when I mark it complete the next one appears for tomorrow. Sometimes I just click it done to move it to tomorrow and get it out of my current list.

Set all your project review dates way into the future and then put a link in the recurring task to get to the project or whatever perspective you need.

Using OmniFocus reviews would be great but if they don’t work maybe a simpler solution would do the trick?

Well, the noise level can be higher using this approach. Consider Projects that need some level of attention. In “standard mode”, you see them ONLY in a Review perspective. In the mode that you propose, you also see an added collection of tasks akin to “update the status of Project XYZ” in any of the other “do me now” perspectives. Do you really know what seeing supposedly the same thing duplicated in one view (Review) versus any others is supposed to mean? Does it really make sense to be prodded by a Project both in the Review perspective AND in other perspectives to “do something with me”? If so, why?

Not to say the approach you propose is “wrong”. Indeed, I use it routinely BUT selectively. The difference in my case is, when I would find myself “just click[ing] on it to move it [out of the way]”, I realize that I am using this approach to cause myself more trouble than it is worth. I should probably at that point just put the offending Project to an On Hold status until I really can do something with it.


Here it is. It could likely be optimized a bit further, and it’s settings are uniquely specific to my intentions. Feel free to modify to fit your needs.

Set OmniFocus Review Cycles

v1.2 JJW

@Admin		-> every Friday
@Bills		-> every Sunday
On Hold		-> 1 month
Active (missing next action means deferred next action)
	missing next		-> 1 week
	has next
		+ Flagged		-> 3 days
		only 1 task left	-> 3 weeks
		otherwise		-> 1 day

on run

set nextFriday to nextWeekday(Friday)
set nextSunday to nextWeekday(Sunday)

tell application "OmniFocus"
	tell front document window of default document to set its perspective name to "Projects"
	tell default document
		-- set reviews of On Hold projects
		set OnHoldProjects to (id of every flattened project whose status is on hold)
		repeat with ProjectID in OnHoldProjects
			set (the review interval of project id ProjectID) to {steps:1, unit:month}
		end repeat
		-- set reviews of Active projects
		set ActiveProjects to (id of every flattened project whose status is active)
		set itsName to ""
		set itsFlag to ""
		repeat with ProjectID in ActiveProjects
			set pName to the name of project id ProjectID
			if ¬
				((pName does not contain "@Admin >") and ¬
					(pName does not contain "@Bills >") and ¬
					(pName is not "Weekly Review")) then
				set NextTaskID to the id of the next task of project id ProjectID
				if NextTaskID is missing value then
					set (the review interval of project id ProjectID) to {steps:1, unit:week}
					if ¬
						((the flagged of task id NextTaskID is true) or ¬
							(the flagged of project id ProjectID is true)) then
						set (the review interval of project id ProjectID) to {steps:3, unit:day}
						if ((the number of available tasks of project id ProjectID) is equal to 1) then
							set (the review interval of project id ProjectID) to {steps:3, unit:week}
							set (the review interval of project id ProjectID) to {steps:1, unit:day}
						end if
					end if
				end if
			end if
		end repeat
		-- this eventually could be done in a loop with {name:"name", step: steps, unit: units} lists
		-- set review of Administrative projects
		set AdminProjects to (id of every flattened project whose name contains "@Admin >")
		repeat with ProjectID in AdminProjects
			set (the next review date of project id ProjectID) to nextFriday
			set (the review interval of project id ProjectID) to {steps:1, unit:week}
		end repeat
		-- set reviews of bills
		set BillsProjects to (id of every flattened project whose name contains "@Bills >")
		repeat with ProjectID in BillsProjects
			set (the next review date of project id ProjectID) to nextSunday
			set (the review interval of project id ProjectID) to {steps:1, unit:week}
		end repeat
	end tell
end tell
end run

on nextWeekday(wd)
set today to current date
set twd to weekday of today
if twd is wd then
	set d to 7
	set d to (7 + wd - twd) mod 7
end if
return today + (d * days)
end nextWeekday



Quite interesting @DrJJWMac!

I don’t have such ids (Admin/Bills/etc) on my project names but liked your approach a lot.
Will sleep over it to eventually come up with a hybrid between your script and @joebuhlig 's one.

Thanks for sharing.

1 Like

I think the most important thing for me to remember (YMMV) in this sort of thing is that not all thing in OF are created equally. In other words, just because it’s in my OF database doesn’t mean it’s especially meaningful, it just means it is captured there to keep it off my mind.

To that end, I totally embrace having stuff that is part of very different review cadences:

  • Daily review: flagged and due tasks (a custom Today perspective), available tasks (a custom Next perspective)
  • Weekly review: all active and on hold projects in my “Outcomes” project folder (a folder that contains parallel and sequential projects have a defined end), all projects in my “Domains” folder (a folder that contains single-action projects representing areas of responsibilities)
  • Monthly review: all projects in my Ideas folder (a folder that contains single-action projects representing someday/maybe outcome projects and single-action projects representing various potentials, such as books to read, movies to watch, gifts to buy, etc.)
  • Quarterly review: a couple of key checklists I keep around performance objectives, goals, etc.

Maybe it’s me, but I can’t get in to the built-in OF Review perspective. I have, instead, tasks to conduct reviews.

The other thing that been very beneficial to me has been creating a variety of someday/maybe type projects and lists to effectively organize things I don’t want to act on now. In this way, I can get things off my mind but still clearly know how to refer back to them (on a monthly review cadence). Projects (all single-action with a project-level someday/maybe on hold context) include:

  • Work outcome project concepts
  • Home outcome project concepts
  • Consulting outcome project concepts
  • Blog post ideas
  • Books to read
  • Gifts to buy
  • Please to see

The keys here in hopes of providing some ideas to the OP:

  1. Find ways to organize and/or define your content so that you review only what needs reviewing - in that way, even if you are reviewing 100 projects, you are going in to the review with the confidence that you are doing what must be done
  2. Use various review kinds and cadences to reduce the effort in each particular review type
  3. Have as many someday/maybe lists or projects as needed to effectively get stuff off your mind mind, out of your way, and out of frequent reviews

Just some thoughts I would add to the thread - this is an awesome discussion, and great inputs here from the group.



I understand this approach entirely. I bounce between using a modification of it and the built-in review depending on need. In particular, rather than setting tasks that say “review this …”, I have a habit now of writing tasks that say “update status of Project XYZ”. I put them in their respective @Admin > Project XYZ project, which itself is a single-action project at the top level of the folder Project XYZ.

The feedback and insights here are helpful to be sure!



Yes, totally! Although, I do like that the built-in review perspective gives a list of projects to review, but only presents one at a time, so I will sometimes set the review date on a bunch of things to today’s date, and a bunch to the future so that I can take advantage of the perspective.

Now that I’ve learned more about Focus, though (thanks, @ediventurin), I might use Focus to determine what to review, then move in to the Review perspective.

That’s clever - so each project has a sub-project/action group to administrate the parent project? Is that how that works? That’s a really smart way of putting together tasks that enable a project (as opposed to helping complete that project’s outcomes). Great idea!


1 Like

Wow. This discussion keeps getting better and better.

Me on the other hand, consider built-in review one of the reasons I can’t even consider moving to another app/solution.

Same here. And I’m now looking forward to finding the time to adapt @DrJJWMarc 's script (probably combining w/ Joe’s script I mentioned before)

Wow! Never thought of Focus & Review combined. Just tried to confirm, and it works. Now I can review my “Life” and “Work” (folders) projects separately as I wish. This is brilliant @deturbulence.

Ha! Just renamed my “Areas of Responsibilities” folder to “Domains”. Like it ;-)


Technically that was your idea, but okay ;)

I am trying to be frugal with characters in folder names, thinking that I will, at some point, get around to building a Workflow for adding to my lists.

Each FOLDER (of specific importance) has a single-action Project entitled @Admin > Project XYZ. This approach applies always for my top-level Areas of Responsibility (AoR) folders. I apply it systematically to lower-level (sub-level) folders depending on the importance of the folder contents. Case in Point: my “Big Rock” sub-folders each have their specific @Admin > BigRock projects, but my “Bills” sub-folder (in my Well-Being AoR) does not.

By further example, I have something already akin to this set up …

Anthologies (top level folder)

  • @Admin > Anthologies (project)
  • Publications (sub-folder)
    – Publication 1 (sub-subfolder)
    @Admin > Pub 1 (project)
    – Figure XYZ (project)
    – Introduction Text (project)
  • Proposals (sub-folder)
    @Admin > Proposals
    – …

I have a “Big Rocks” perspective and an “@Admin” perspective to review selectively each topic. In the former case, the @Admin > BigRock projects show up (somewhat at the top of each “folder”). In the latter case, I see every @Admin > XYZ project that exists (it is a search-based perspective).


1 Like

Great thread and now I don’t regret bringing it up!

I really wanted to preserve the day of the week that some of these projects are getting reviewed. So I rolled my own script to reset review dates. Basically what it does is finds all the projects that are overdue for review. Then it calculates what the review date should be, such that its no longer overdue and as if I had been in my usual daily flow where I am marking projects reviewed as they appear in the review perspective each morning. Once calculated it applies that new review date.

--	Created by: Mark Parry
--	Created on: 9/18/16
--	Copyright (c) 2016
--	All Rights Reserved

use AppleScript version "2.4" -- Yosemite (10.10) or later
use scripting additions

on run {}
	set projectsPastReview to getOverdueProjects()
	set newReviewDates to getNewReviewDates(projectsPastReview)
	setNewReviewDates(projectsPastReview, newReviewDates)
end run

on getOverdueProjects()
	local theOverdueProjects
	local today
	set today to (current date)
	tell application "OmniFocus"
		tell default document
			set theOverdueProjects to every flattened project where its next review date is less than today
		end tell
	end tell
	return theOverdueProjects
end getOverdueProjects

on getNewReviewDates(projectsPastReview)
	local newReviewDates
	set newReviewDates to {}
	repeat with projectPastReview in projectsPastReview
		local newReviewDate
		set newReviewDate to calculateNewReviewDate(projectPastReview)
		set end of newReviewDates to newReviewDate
	end repeat
	return newReviewDates
end getNewReviewDates

on calculateNewReviewDate(projectPastReview)
	tell application "OmniFocus"
		tell projectPastReview
			set lastReview to last review date
			set reviewInterval to its review interval
			set newReviewDate to my playReviewDatesForward(lastReview, reviewInterval)
			return newReviewDate
		end tell
	end tell
end calculateNewReviewDate

on playReviewDatesForward(lastReview, reviewInterval)
	if lastReview is greater than (current date) then
		return lastReview
		tell application "OmniFocus"
			local reviewUnits
			set reviewUnits to unit of reviewInterval
			local reviewSteps
			set reviewSteps to steps of reviewInterval
			if reviewUnits is hour then
				set lastReview to (lastReview + (reviewSteps) * 3600)
			else if reviewUnits is day then
				set lastReview to (lastReview + (reviewSteps) * 86400)
			else if reviewUnits is week then
				set lastReview to (lastReview + (reviewSteps) * 604800)
			else if reviewUnits is month then
				set lastReview to (lastReview + (reviewSteps) * 2419200) --This needs to be fixed up
			else if reviewUnits is year then
				set lastReview to (lastReview + (reviewSteps) * 29030400) --This needs to be fixed up
			end if
		end tell
		return playReviewDatesForward(lastReview, reviewInterval)
	end if
end playReviewDatesForward

on setNewReviewDates(projectsPastReview, newReviewDates)
	repeat with n from 1 to length of projectsPastReview
		tell application "OmniFocus"
			local currentProject
			set currentProject to item n of projectsPastReview
			local newReviewDate
			set newReviewDate to item n of newReviewDates
			set last review date of currentProject to newReviewDate
		end tell
	end repeat
end setNewReviewDates
1 Like