Tasks & the board
The backlog: where work comes from, what a task holds, and how running it works.
The backlog is where work waits, whichever door it came in through — typed by hand, synced from a tracker, filed over the API, captured from Slack, or moved in wholesale with an import.
Every task remembers where it came from, and each origin keeps its own vocabulary.
Archiving
A finished task can be filed away: it leaves the board and the backlog without being deleted, and its history, its runs, its comments and its place in a milestone are all untouched. Reach the archive from the board — Archived on the dashboard and the desktop app, the archive box in the toolbar on the phones and the Mac, and its own Archived Tasks view in the editor.
Only a finished task can be archived — one in a done or canceled status. A task you have decided against is canceled first, which keeps the record honest: an unfinished task filed away is something that will demand attention later, hidden in the place you look when you have decided nothing will. Anything filed away can be put back, and a task moved back into a live status comes out of the archive by itself.
Templates
A template is a task somebody already thought about: the headings a bug report should have, the status a chore lands in, the person who usually takes it — and the workflow that runs it. Pick one at the top of the New task form and it fills the form in; everything it sets stays editable, and nothing is written until you press Create.
That last field is the one no other tracker has. A template pairs a kind of work with the agent that does it, so Create and run on a templated task is one press from an unformed thought to a working agent.
Templates are defined in Settings → Peractor Tracker → Templates on the phones and the Mac, and on the Tasks page on the dashboard and in the editor. A project with none shows no picker at all. One shorthand is worth knowing: a cycle of current means whichever cycle is running when the task is filed — between cycles it means none.
Your organization can keep templates too, written once and offered to every project — an incident report, a security review, whatever shape your team files the same way twice. They live in Organization settings → Task templates, and each project switches on the ones it wants on its own Templates screen; an unticked one simply isn't in that project's picker.
A shared template names its status and its labels by name rather than by choice, because the organization cannot see any one project's board. Each project matches those names against its own, and one that has no such status leaves that field blank — the switch says so before you turn it on, and it is never a reason you can't use the template. Milestones and cycles don't travel at all: those belong to one project's backlog.
Wrote a good one in a project? Its editor has Share with the organization, which copies it up — your project keeps its own either way.
Creating a task
New task — in the editor sidebar, the dashboard, the Mac app, or a phone — takes a title and description. Where they exist you can also set status, priority, assignee, labels, estimate, due date, milestone, cycle, and which workflow it should run. Create and run does both in one press.
Tasks you create here are yours to edit and delete. Tasks synced from a tracker are read-only in their core fields — the tracker stays the source of truth for the title, description, and its own labels, so you move the issue on its own board and Peractor follows within seconds. Everything Peractor adds on top, you can still edit.
What a task holds
| Field | Notes |
|---|---|
| Key | WEB-14 — the handle. It names
the branch, prefixes the pull request title, matches exactly in search,
and autocompletes after @ in a comment. An imported task
keeps its old key too, so ACME-12 still finds it. |
| Status | Which status it is in. See below. |
| Priority | A per-project list, with a built-in Urgent / High / Medium / Low fallback so the field always works. |
| Assignee | Anyone in your organization. |
| Labels | Your own labels, defined per project. A synced task also shows its tracker's tags; the two are different things that both look like chips. |
| Estimate | Points on the project's scale — none, linear, Fibonacci, exponential, or t-shirt sizes. Set the scale in project settings. |
| Due date | Filterable as overdue, today, this week, or none. |
| Sub-tasks | Any task can be a parent. Children are listed on it and roll up into progress. |
| Relations | Blocks, blocked by, relates to, duplicates. Written on both tasks, so "is this blocked" is answered on every row. See When two tasks are the same thing below. |
| Milestone & cycle | See Milestones, cycles & triage. |
When two tasks are the same thing
Somebody files it, somebody else files it again, and now there are two. Merge into… — on the task's own page on the dashboard and the desktop app, in a row's menu on the phones and the Mac, and on a row in the editor — asks which task this one duplicates and closes it into that one.
It is a close, not a delete. The duplicate keeps its key, its
history and its runs: WEB-14 is in a branch name, a pull
request title and three commit messages, and it still resolves next year.
It moves to a canceled status and into the archive, marked as a duplicate
of the one that stays.
What moves with it is the work: the conversation, the sub-tasks, and every link pointing at it. What stays is what the surviving task's owner chose — its labels, its estimate, its milestone — and its runs, since a run is a record of work done on that task. The confirm counts what is about to move before you press it.
Two things it will not do. A task belonging to a connected tracker cannot be merged here, because closing it would write that status back to the tracker that owns it — import it first, or close it there. And your project needs a canceled status for a duplicate to go into.
Your board, your statuses
Peractor ships with no built-in statuses. Until you define statuses the task list is a flat list, which is all a solo flow needs.
Define statuses in the editor's Statuses view or the dashboard's Tasks → Statuses tab — one per status:
# status/in-spec.yaml
id: in-spec
name: In Spec
icon: file-text
color: blue
category: unstarted
order: 20Category is the field that does the most work. It is one of
triage, backlog, unstarted,
started, completed, or canceled,
and it is what lets Peractor order your statuses, compute progress, and
know which of them mean "done" — without you maintaining a list of
done-ish names.
With statuses defined, the panel becomes a board. Every column renders, including empty ones, plus a "No status" column for strays. How it is filtered, grouped, and ordered is a view you can save.
Trackers you connect get their own boards alongside, each mirroring that tracker's real statuses: Linear's workflow states, a Jira project's statuses, a GitHub Projects board. There is no mapping table — a task lives in its origin's vocabulary.
Dragging a card can start work
Workflow phases can bind to statuses in both directions: entering a status starts a workflow at a phase, and finishing a phase moves the task to another status. So dragging a card is how work starts. See status automation.
Comments and history
Every task has a conversation and a record, interleaved into one timeline on its detail screen.
- Comments support one level of replies, attachments, and
@mentions that notify the person named. - Agents comment too. A run posts to its task's thread when it starts, when it parks for review, and when it settles — each with a link straight into the transcript. Turn it off per project if you would rather the thread stayed human.
- Activity is written automatically: created, status, assignee, priority, estimate, due date, labels, milestone, cycle, parent, relations, title, runs starting and settling, triage, archive. Nothing changes a task without leaving a line.
- Subscriptions follow what you touch — create, get assigned, comment, or get mentioned and you hear about the next comment. Unsubscribe from a noisy task at any time.
Running work from a card
Every task row offers Run and Run with workflow…. A task holds one active run and the full history of earlier attempts, each listed on the task and replayable read-only. See the run lifecycle.
Attachments travel with the task
Files on a task — pasted in, dragged on, shared from your phone, or arriving on a synced issue — are staged into the run's workspace before the agent starts, with their paths listed in its prompt. So "fix the layout in this screenshot" just works.
Limits: 10 MB per file, and 25 MB across at most 10 files per run. A file that cannot be fetched becomes a note in the run log, never a failed run.