Get AI summaries of any video or article — Sign up free
Notion FINALLY Made Recurring Tasks Work. thumbnail

Notion FINALLY Made Recurring Tasks Work.

5 min read

Based on Thomas Frank Explains's video on YouTube. If you like this content, support the original creators by watching, liking and subscribing to their content.

TL;DR

Store recurrence rules in database properties (at minimum recur interval and due date) so Notion can compute the next schedule automatically.

Briefing

Notion’s new native recurring tasks support can now automatically push due dates forward when a task is marked complete—without relying on external apps like Todoist or TickTick. The core setup pairs a “recur interval” field (how far to move the due date) with an automation (or a button) that runs when task status changes to done, then uses a date-add formula to calculate the next due date and resets status so the task can be checked off again.

The simplest implementation starts with a tasks database that includes at least a due date and a status. To make recurrence work, an additional property—typically a number called “recur interval”—stores how many days to add after completion. A button-based approach can work on free plans: clicking a “complete” button triggers an action that edits the due date using Notion’s dateAdd function and the task’s own recur interval value. For more “native” behavior, automations are the next step: when status is set to complete, an automation edits the due date to the next scheduled date and changes status back to not started.

A key limitation appears immediately: non-recurring tasks would also get reset unless the automation is scoped. The fix is to create a filtered view (e.g., only tasks with a due date and a recur interval of at least 1) and configure the automation to trigger only for pages inside that recurring view. With that guardrail, tasks that aren’t meant to repeat can remain done permanently.

The next challenge is calendar reality. A naive “add 31 days” approach breaks on months with fewer days. To handle this, the setup evolves from a fixed “days” unit to a dynamic “recur unit” property (days, weeks, months, years). The automation then uses the recur unit value as the unit argument to dateAdd, including a formula trick to normalize the unit text into the exact lowercase format Notion expects. This enables robust monthly and quarterly schedules, such as shifting a “review monthly budget” task to the correct next month even when the day count varies.

For advanced recurrence—like “every Monday/Wednesday/Friday,” “last weekday of the month,” or “first weekday”—the workflow shifts from building complex logic inside each automation to using prebuilt formulas and template-ready properties. The template approach adds extra recur-unit options (e.g., months on the first weekday, last weekday, last day) plus a multi-select “days” property for specific weekdays. A crucial improvement is computing a “next due” formula inside the database, then having the automation simply set the canonical task’s due date to triggerPage.nextDue. That keeps the automation lean and makes upcoming schedules visible at a glance.

Finally, task history turns recurrence into habit tracking and compliance-friendly auditing. A “completed” timestamp property records when each occurrence was finished, while a self-referential relation (“occurrences”) links each historical instance back to a canonical recurring task. When the canonical task is completed, an automation creates a new page in the same tasks database as a historical record, copies relevant properties, sets its status to done, and relates it back to the canonical task. The result is a task history list, table, and chart view that shows when each occurrence was due and when it was actually completed—turning recurring tasks into a measurable timeline.

Cornell Notes

Native recurring tasks in Notion work by combining a recurrence rule (like a “recur interval”) with an automation that fires when status changes to done. The automation calculates the next due date using dateAdd and then resets status so the task can be checked off again. To prevent one-time tasks from being affected, the automation is restricted to a filtered “recurring” view (e.g., tasks with a due date and recur interval). Calendar edge cases are handled by adding a “recur unit” property (days/weeks/months/years) and normalizing its value for dateAdd. For richer schedules and history tracking, templates add advanced recur units (first/last weekday, specific weekdays) and create separate historical pages linked back to a canonical recurring task, enabling charts and audit trails.

How does Notion calculate the next due date when a recurring task is completed?

The setup stores a recurrence amount in a property such as “recur interval” (e.g., 7 for weekly). An automation (or button) runs when status is set to complete, then edits the due date using dateAdd. The formula uses the task’s own values via triggerPage (automation) or page context (button), passing dateAdd(triggerPage.due, triggerPage.recur interval, unit). Initially, the unit can be fixed (like days), but later it becomes dynamic using a “recur unit” property.

Why is a filtered view necessary, and what does it protect against?

Without scoping, the automation would trigger for every task marked done, including one-time tasks. The fix is to create a view with an advanced filter such as: recur interval ≥ 1 and due date is not empty. Then the automation is configured to trigger only for pages in that recurring view, so tasks like “find the snipe” stay done permanently.

How do recurrence rules avoid breaking on months with fewer than 31 days?

Instead of hardcoding “31 days,” the system introduces a “recur unit” property (days/weeks/months/years). The automation uses dateAdd with the unit coming from recur unit, so adding “1 month” moves to the correct next month regardless of day counts. A formula trick normalizes the unit text (removing parentheses and forcing lowercase) so it matches Notion’s expected unit argument format.

What’s the advantage of computing “next due” as a database formula instead of embedding logic in the automation?

A “next due” formula makes the schedule visible directly on each task page and keeps automations simpler. The automation can then just set the canonical task’s due date to triggerPage.nextDue. This matters especially for advanced recurrence (first/last weekday, specific weekdays), where the logic can be large and error-prone if repeated inside the automation.

How does task history work without losing the original recurring task logic?

Task history is implemented by creating separate historical pages for each completion. A relation property like “occurrences” links each historical record back to a canonical recurring task. When the canonical task is completed, an automation adds a new page, copies properties from the canonical task, sets the historical page’s status to done, sets its due date to the occurrence’s due date, and relates it back via occurrences. The history view filters to show only pages related to the canonical task, enabling lists, tables, and charts.

Review Questions

  1. What properties and triggers are required for the simplest recurring-task automation in Notion?
  2. How does the filtered recurring view prevent one-time tasks from being reset?
  3. In the task-history setup, what role do the “occurrences” relation and the “completed” timestamp play?

Key Points

  1. 1

    Store recurrence rules in database properties (at minimum recur interval and due date) so Notion can compute the next schedule automatically.

  2. 2

    Use an automation triggered by status changing to done, then edit the due date with dateAdd and reset status back to not started.

  3. 3

    Scope automations to a filtered recurring view (e.g., recur interval ≥ 1 and due date not empty) to avoid breaking one-time tasks.

  4. 4

    Handle month-length variability by adding a dynamic recur unit (days/weeks/months/years) and normalizing its value for dateAdd.

  5. 5

    For advanced schedules, compute next due as a formula property and let the automation simply apply triggerPage.nextDue.

  6. 6

    Implement task history by creating separate historical pages linked back to a canonical recurring task through a self-referential relation (occurrences).

  7. 7

    Use completed timestamps plus list/table/chart views to turn recurring tasks into measurable habit tracking or audit trails.

Highlights

Recurring tasks become “native” when an automation recalculates due dates with dateAdd and resets status automatically after completion.
A filtered view is the safety mechanism that stops the automation from affecting non-recurring tasks.
Dynamic recur units (months/years) fix the classic “31 days” problem by letting dateAdd handle calendar length correctly.
Task history is built by spawning new pages per completion and linking them back to a canonical recurring task, enabling charts of actual completion frequency.

Topics

Mentioned