Triage, intake & recurring work

Where inbound work lands

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.

The triage queue

The triage queue is your inbox of untriaged inbound work across your active projects. You reach it from Triage in the sidebar. Every item is a real work item flagged for triage: it has an identifier, a title, a description, a priority, and a home project, but it has not yet been accepted onto the board. The queue is ordered newest first, so the most recent arrivals are at the top.

The page is built to be cleared fast. A focused card at the top shows the current item in full, and a compact list below shows the rest of the queue. The header tells you how many items are waiting and across how many projects, for example "7 items to triage across 3 projects". When the queue is empty you see Triage zero.

Processing one item at a time

Triage is designed around a single focused item rather than a bulk grid. You move through the queue with the keyboard: arrow down and arrow up move focus to the next or previous item, and enter opens the focused item in its project for a closer look. The focused card shows the project key, the identifier, the priority, when it was created, and, when the item came from a known channel, a small badge naming that channel (for example in-app or form).

The single-key actions

Each item is resolved with one of four decisions, each bound to a single key so you can clear the queue without reaching for the mouse:

Accept, mark duplicate, and decline all resolve the item: accept and duplicate by taking it out of the triage flow, decline by closing it. Snooze is the one action that keeps an item in triage but hides it temporarily. Every decision is written to the activity log against the item, so the history of how a request was handled is preserved.

Accepting into a status

Accepting does not just dump the item onto the board, it places it at a workflow status. From the triage card, the accept key moves the item into To do so it is immediately actionable, which is the right default for most requests. The accept endpoint can also target any of the board statuses (Backlog, To do, In progress, In review, Done, Cancelled), so a request that is already half-done can land further along. Accepting always clears the snooze, so an accepted item never quietly reappears.

Snooze and resurfacing

Snoozing sets a time in the future and removes the item from the open queue until then. It is not resolved, it is deferred. Once the snooze time passes, the item is counted and shown again exactly as before. This keeps the queue honest: things you are not ready to decide on do not clutter the list, but they also do not silently disappear.

Open and closed views

The queue has two tabs. Open is the live work: unresolved items that are not currently snoozed, newest first. Closed holds the declined items, the ones you cancelled out of triage, so there is always an audit trail of what was turned down and why. Accepted and duplicate-resolved items leave triage entirely and live on as ordinary tasks on the board, so they are not in either tab.

Count badges

Triage drives count badges so you always know how much is waiting. Elliptic tracks an org-wide total of open triage items plus a per-project breakdown, and these counts feed the badges in the navigation. The counts only include items that are genuinely actionable right now: snoozed items and already-resolved items are excluded, so the number you see is the real size of the decision backlog, not a running tally of everything that ever arrived.

Public intake forms

A public intake form gives a project a link that anyone can use to submit a request, with no Elliptic account required. It is how you collect bug reports, feature requests, or support asks from customers and outsiders without giving them access to your workspace. Every submission lands in the project's triage queue as a new item, tagged with the form channel, so it flows through the same one-key process as everything else.

Enabling the public link

1. 1
   Enable intake for the project

   An admin turns on the public intake form for a specific project. Enabling is project-scoped: each project has its own form and its own link. The first time you enable it, Elliptic mints a unique, hard-to-guess public token for that project.
2. 2
   Share the link

   The token is the project's public form address. Anyone with the link can open the form, which shows only the project name and the organization name, and submit a request. No internal identifiers, member lists, or board contents are exposed.
3. 3
   Watch submissions arrive in triage

   Each submission becomes a triage item in the project, with the title and description the submitter entered. If the project has an intake owner set, that person is notified of the new submission.

What a submission contains

The public form collects a required title and an optional description, plus an optional name and email for the submitter. When a name or email is provided, Elliptic appends a short "Submitted via intake form by ..." line to the item's description so you can follow up. The new item starts in Backlog, in the triage queue, waiting for a decision.

The returned reference

After a successful submission, the form returns a reference to the submitter, the work item's identifier in PROJECT-NUMBER form (for example WEB-142). This is the same identifier the item carries inside Elliptic, so a submitter can quote it when they follow up, and you can find the exact item they mean. The submitter also sees a short confirmation that the request was received.

Rate limiting

Because the public endpoint takes anonymous traffic, submissions are rate-limited to 10 per minute. This is enough for normal use while protecting the queue from being flooded by a script or an abusive client. Reading the form (to render it) is separate from submitting it, and is not rate-limited.

Admin enable and disable

Enabling and disabling the public form is an admin action. Disabling turns the link off immediately: the form stops accepting and stops rendering. The token itself is preserved but inactive, so if you re-enable the same project later, the previous link keeps working rather than breaking every place you posted it. You stay in control of when the door is open.

In-app intake

In-app intake is the inside-the-workspace counterpart to the public form. When an admin enables it for a project, members of the organization, including guests, can submit a request straight into that project's triage queue from within Elliptic, without needing edit access to the board itself. The item is tagged with the in_app channel so you can tell it apart from public submissions.

This is the right channel when someone belongs to your org but should not be dropping work directly onto a team's board: a guest stakeholder, or a member from another team who wants to file a request and let the owning team triage it. The submission carries a title and an optional description and is attributed to the member who created it. In-app intake is a separate toggle from the public form, so you can run one, both, or neither per project.

Custom intake forms

When a single title-and-description form is not enough, you can build a custom intake form for a project: a public form with your own ordered set of fields. Like the basic public form, a custom form has its own public token and submits straight to the project's triage queue. A project can have more than one custom form, each with its own link and field set, so you can run, say, a bug-report form and a feature-request form side by side.

Configurable fields

Each form holds an ordered list of fields that you define. A field has a label, a type, and a required flag, and is rendered in the order you set. The supported field types are:

Marking a field required forces the submitter to fill it in before they can submit. The order you arrange the fields in is the order respondents see, so put the most important questions first.

Building and managing a form

1. 1
   Create the form

   Give the form a name and add its fields in order, choosing a type and a required flag for each, plus options for any select fields. Elliptic mints a public token for the form when you create it.
2. 2
   Edit it as needs change

   You can rename a form, rewrite its field set, or enable and disable it. A disabled form stops accepting submissions without losing its configuration.
3. 3
   Share the public link and collect submissions

   The form's token is its public address. Respondents see the form name and your configured fields, with no account needed. Each submission carries a title plus the answers to your fields, rendered into the item description, and lands in the project's triage queue alongside every other inbound item.
4. 4
   Delete when retired

   Removing a form takes its public link out of service for good.

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.

Where intake comes from elsewhere

The forms on this page are intake you build inside Elliptic, but plenty of inbound work originates in your other tools and in AI. Those paths all converge on the same triage queue.

Triage automations and skills

Triage does not have to be all manual. You can attach automations and AI skills that label, route, assign, prioritize, or pre-classify incoming items, and run a skill on the focused item from the triage card. These are configured on the AI, Brain & Automations page, and like every AI feature in Elliptic they execute on your organization's own model key.

External sources

Inbound items can also flow in from outside Elliptic: GitHub issues and pull requests, Sentry alerts, inbound email, and a Slack slash command for filing requests without leaving chat. Each of these lands in triage tagged with its source channel (github, sentry, email, or slack), so it is handled with the same one-key flow as a form submission.