Recurring Tasks: Add User-Level Control for Notification Timing (Actionable vs Up-Front)

Alexandra Torres

Hi Wrike Community 👋

In our enterprise, recurring tasks are a core workflow used across teams to keep operational work consistent and on track. We rely heavily on Inbox notifications as a signal for what’s actionable now, not just what exists in the system.

However, here’s the challenge: recurring task notifications are currently tied to when the task instance is created/assigned, not when the work becomes relevant to start. Wrike Support clarified that Inbox notifications are triggered by assignment at the time a recurring task is created, and the “Create X tasks upfront” setting determines how far in advance future instances exist (which can mean notifications arrive weeks/months early depending on recurrence frequency and upfront count). When upfront creation is disabled (or minimal), new occurrences are created just before the start date, but when upfront is enabled, task creation follows the interval logic rather than a consistent “notify shortly before start” rule.

This creates a real user experience issue: early notifications cause confusion and inflate perceived workload, contributing to feelings of overload (and burnout risk) because users are being notified about work that isn’t actionable yet.

Proposed Solution

We’d love to see a user-level notification preference for recurring tasks that lets each individual choose how notifications arrive, for example:

• Up-front cadence (current behavior: notify when the recurring task instance is created/assigned), or
• Actionable timing (notify X days before the start date / “N workdays before start”)

This would preserve planning visibility (teams may still want tasks created upfront), while aligning notifications to when users can actually act.

Why this would help

• Reduces confusion by aligning notification timing with actionability
• Lowers cognitive load and perceived overload from future work
• Increases trust in Inbox notifications (less “noise,” more signal)
• Scales well because recurring tasks are a foundational pattern for many teams

Bonus context: Support also noted Inbox notifications have a limited visibility window (“live” for ~4 weeks), which makes it harder for users/admins to audit and understand notification timing after the fact. A preference-based approach would reduce the need for investigation in the first place.

If others are seeing similar challenges, especially in environments using upfront task creation for planning, I’d love your votes and any examples of how early notifications impact your teams.

Thanks for considering! 🙌

Devree Czupinski

I completely agree with @Alexandra Torres!

We heavily utilize recurring tasks to keep track of individual instances of each report we run on a cadence. These tasks are our source of truth of what should be delivered when. We typically recommend that our team create a few more instances ahead of time (for workload planning purposes). Therefore, we run into the same issue that what ends up appearing in our email/inbox is the instance that is weeks, months, quarters out.

Having the option to control when you are alerted as Alexandra mentions would be really useful. We are able to set up automations today (we have some set up for our development tickets), but it wouldn't remove the extra notifications months/quarters out of the next recurring task being created.

One additional item related to notifications would be the ability for someone else to alter/edit the recurrent task without then being the one getting notified. We often pass projects from team member to team member, and if you set up the original recurrent task, it feels extremely difficult to remove yourself from being a "follower" for all recurring tasks even when they aren't assigned to you, leading to even more emails!