Protected repeaters

We’ve got work we do monthly, such as sending emails, social media content, creating reports, etc.

For the project management jobs - tracking where these are at - we currently use a single task for each monthly task with subtasks to track, with a repeater on this task, so once it’s finally ticked off, it regenerates for the NEXT month.

One problem is that I’ve had staff accidentally remove the repeater when adjusting the task date, and then we lose the whole task, causing us miss work. We want to be be able to alter the active task due date (e.g. the next date they would follow up that task, such as when design is ready, vs sending to print, etc)

Pre-creating the month of tasks makes the jobs unwieldy, as the single tasks serve as a great single source of truth. I also want to have these task have their actual due date moved around, without breaking the repeater.

I’d love a way to protect the repeater tasks to prevent this from happening.

A possible solution may be protected repeaters (where the repeater can be locked in once it’s set, perhaps) and require a more deliberate step to alter it (e.g. the ability to separate the repeater nature completely from the due date).

1 Like

Can you expand on why having a monthly project template including all (non-repeatable) tasks is an issue?

I did originally have things set up in this way, but it wasn’t working well for us.

An example would be a typical retainer where we track each month:

  • A social media plan
  • 3 email blasts
  • A monthly report
  • A monthly meeting
  • Weekly check-ins on digital ads team
  • Weekly check-ins on social media team
  • Creation of a monthly print newsletter
  • Monthly invoicing tasks
  • Monthly strategy meeting

Those jobs are all set up as repeaters, so at any time you can jump into the job and see where each of those tasks is up to for the month (we use subtasked templates on each job).

We also have separate sections in the jobs for approval and admin tasks.

This gives the whole team a clear snapshot of where things are at. Once the task is completed, ticking it off moves it to the next date, and resets the subtasks.

If we were to build out a whole 12 months of that job it’d take ages and you would end up with an overwhelming sea of tasks.

It also becomes challenging each year to set up all those new retainer jobs for all the clients, and it’s way less flexible in the event that a client alters the activity in the retainer (which happens often enough to make it challenging).

The repeater system has been working really well, except for edge cases where someone changes a task date and accidentally removes the repeater.

I’m not 100% sure what specific action makes the repeater date get lost, as it doesn’t always happen. At the moment, I think it’s the date being removed by accident (little x) when a user is trying to alter the date, and then putting the date back manually, but still trying to deduce the actual behaviour.

I was suggesting a monthly template.

I agree with your analysis. Using recurring tasks is:

  1. Super risky
  2. Not ideal because the next task inherits from whatever was done on the previous one, including description update, new collaborators, and attachments.

So to me, using a recurring task is not the right approach in your case. If I were to recreate the right system, assuming I understood what you’re trying to do, I would have a monthly template and then the different type of tasks would be multi-homed into buckets.

For example, all these three email blasts from January would go to a project where all the email blasts are listed (that’s one bucket). Each monthly meeting would live in each month project as well as a monthly meetings project (another bucket). etc

This is an approach we’ve used again and again with lots of clients, and I feel like it gives you the best of all worlds: flexibility and visibility.