Open app →
Documentation

Recurring work

How recurring rules materialise work on a schedule, so routine jobs appear without anyone remembering them.

Work that repeats

Some work comes back on a rhythm: a weekly report, a monthly access review, a quarterly backup restore test. A recurring rule describes that work once and materialises a fresh task each time it is due, so the routine does not depend on anyone remembering it.

Not all work starts as a clean task on the board. Requests arrive from outside the team, from people without an account, from forms, from AI, and from your other tools. Elliptic funnels all of it into one place called triage, a single inbox of untriaged inbound work that you process one item at a time. This page covers the triage queue itself, the intake channels that feed it (a public link, in-app member requests, and custom forms), and recurring rules that create work on a schedule. The AI side of triage, the automations and skills that label and route items, is covered on the AI, Brain & Automations page.

Triage is agent-shaped too
Triage is a normal Elliptic surface, so your AI members can work it over the company-brain MCP, on your org's own key. An agent can read the queue, accept an item into its project, or decline one with a reason, through the same tasks the web app acts on. That is what makes triage automation possible, rather than a bolted-on rules engine. Marking duplicates, snoozing, and accepting into a specific status are web actions today, not exposed as agent tools.

Recurring work items

Some work is not inbound at all, it is predictable. A weekly report, a fortnightly dependency review, a monthly cleanup. A recurring work item rule is a template that automatically creates a work item on a fixed day-interval cadence, so the task shows up on its own when it is due instead of relying on someone to remember. Rules are project-scoped.

What a rule defines

A recurring rule is a small template plus a cadence. The template carries the fields that every generated item should start with:

  • Title and an optional description, copied onto each created item.
  • Priority, from None through Urgent.
  • Kind, the work-item type: task, bug, story, or epic.
  • Assignee, an optional person the item is assigned to on creation.
  • Interval, the cadence in days, from 1 to 365.

Each time the rule fires, it creates a fresh work item in the project from this template. Generated items start at the To do status, so they appear as ready-to-work tasks rather than landing in triage. The rule tracks when it will next run and when it last ran.

The cadence

The cadence is a plain day interval: every 7 days, every 14, every 30, and so on. You can also set when the rule should first run, which defaults to now. Elliptic advances the next run time forward by the interval after each firing, so the rhythm stays steady even if a run happens a little late.

Pausing, resuming, and running on demand

Each rule has an active flag you can toggle. Pausing a rule (turning it inactive) stops it from generating items automatically without deleting it, so a seasonal or temporarily irrelevant routine can be parked and brought back later. Resuming flips it back on. You can also run a rule on demand, which creates one item immediately from the template, independent of the schedule, useful when you need this week's instance early. Editing a rule lets you change the template fields, the interval, the next run time, the assignee, or the active state at any time.

Recurring rules versus templates
A recurring rule is for work that should appear on a schedule with no one prompting it. If you instead want a reusable scaffold that a person picks when creating a work item by hand, that is a work-item template, covered on the Projects & Tasks page. Rules fire on a clock, templates are chosen on demand.