How work is organized

Organization → Project → Sub-project → Task. Projects and sub-projects are accountable to a named lead; teams are sharing groups.

An organization is your company. It is the only top level: the sidebar lists every project you can see, in one list, with no workspace to switch between. The organization owns the users, the seats, and org-wide settings such as the date format, the calendar-week rules, the attachment size cap and the label list.
A team (e.g. Development, Marketing) is a group of people you can add to a project together. Sharing with a team gives its members access; joining or leaving the team updates that access automatically. A team has a leader who manages its members. Teams can be shared with products or individual sub-projects through explicit access grants. How many hours a week someone can be planned for belongs to the person (§10); task staleness, auto-archiving and delay tracking are project behavior, not team settings. Project sharing is described in §12.
A project is a product that links several sub-projects into one roadmap and board. It has a lead, but no owning team; share it with several teams and individual users when they need access. Its sub-projects inherit that access.
A sub-project is a discipline workstream with its own board and its own lead. It is the only place tasks can live. While a project has no sub-projects its board offers nothing to create a task with: add a sub-project first.

The task#

Every task carries:

Status — Backlog, To Do, In Progress, In Review, Done. A task with active subtasks is a group: its own status is hidden and does not affect its children, completion counts or planning. Its progress comes from the tasks without subtasks underneath it. Removing, moving away or archiving the last active subtask makes it an ordinary task again, with its previous status restored. A To Do, In Progress or In Review task can also be put on hold from the same menu without changing its status; see Paused below.
Priority — Urgent, High, Medium, Low.
Assignee — one active person or agent (or Unassigned) with Edit or Lead access to the project. Someone with only View permission, an organization Viewer (§14), or someone switched off cannot be selected. Access inherited through teams and the parent project counts; the strongest applicable role wins under the organization Viewer ceiling. Reducing access to View keeps existing assignments, but prevents new selections.
Reviewer: one person or agent (or no one) who checks the work once it reaches In Review. Who can be chosen, and what a downgrade to View keeps, follow the Assignee rules above; the reviewer may also be the assignee. While a task is In Review with a reviewer set, the task belongs to the reviewer: it shows in their My view, the My tasks and Assignee filters match them, Swimlanes by assignee puts it in their lane, card, roadmap and task-list portraits show them, Team utilization, auto-fit, the PlanCard, the delay projection and Update Estimate count it as their work, and they start following it (§11). In every other status the reviewer shows only in the task window, and a Review task with no reviewer stays with its assignee. A task with subtasks has no reviewer of its own and belongs to its assignee; set reviewers on its subtasks. Removing someone from the organization clears them as reviewer, as it clears them as assignee.
Reporter — the person or agent credited with reporting the task. It is set when the task is created and cannot be changed or cleared afterward. In the app, the signed-in user is automatically the reporter; there is no reporter picker. REST and MCP task creation can name another existing user in the task's organization who can see its project. Omitting the reporter uses the caller; an invalid selection is refused. Reporting is attribution, not assignment: a Viewer or switched-off user may be the reporter when they can see the project, and becoming a reporter grants no access and sends no notification. The read-only row shows the reporter's picture and name. The value clears only if that profile is removed from the organization; losing project access or moving the task leaves its reporter unchanged. The Assignee and the Reviewer must still be eligible in a move's destination; clear or change them before moving if either cannot edit the destination project or is switched off. A task with subtasks shows no Reviewer, so its move is never refused for one: a reviewer kept from before it had subtasks is removed instead when they cannot edit the destination.
Remaining — finite, nonnegative hours of work left, saved to one decimal place, not an original estimate. This single number drives the team strip, the auto-fit planner and the delay projection — and every save is stamped with when it was made, because a remaining time is a measurement: the planning math spreads the hours forward from that moment (or from the planned start, whichever is later), and assumes progress since (§7). A task with subtasks has no remaining time of its own: its Remaining shows the sum of its subtasks (recursively, marked Σ) and can't be edited — the hours live on the subtasks. The moment a task gains its first subtask, its own hours clear for good; once the last subtask is gone the field becomes editable again, starting empty. Linked tasks never count toward the sum — only the parent → subtask tree does. Enforced everywhere, even against API writes. An empty box and a 0 mean different things, and the field keeps them apart: empty is "not estimated yet" and shows "—", while 0 is a real answer — "nothing left to do" — and shows a literal 0. Nothing rewrites a 0 behind your back (tabbing through the field is not an edit), with two exceptions. The subtask rule above clears a 0 exactly as it clears any other value. And moving a task into In Review sets Remaining to the project's review time (2 h unless the project sets another, §7), saved as a new measurement; an API call that sends its own remaining hours with the move keeps them. Leaving In Review keeps whatever is there.
Due date — the day it must be finished by, at the latest. Plan dates and due dates must be real calendar days; impossible dates are refused. The today marker and overdue checks refresh at local midnight and when you return to a sleeping tab. Existing plans keep their calendar dates.
Planned period — a start → end week pair that puts the task on the roadmap. Qivo plans in whole weeks on purpose (see §6).
Paused — work on hold, say for the week a spare part is on order. Pause is the last row of the task's Status menu and reads Resume while the task is paused; the task keeps its status. A paused leaf task’s window shows an amber Paused tab at the center of its top edge, without moving the title, fields or discussion. Its pause icon has a heavier outline; the tab is smaller on phones. The selected Status control shows only the status. While paused, desktop layouts with enough room show a green play button immediately beside it to Resume without opening the menu, using the same editing permissions. It does not move the selector or other fields. On phones and in narrower layouts, use Resume in the Status menu; that action also has a green play icon. Board cards, phone task rows and the Overview keep their small amber pause marks, and the Roadmap hatches the task's bar with diagonal lines (§6). While a task is paused its remaining hours stop counting as its owner's load (§2), so that person is free for other work: Team utilization, auto-fit and other tasks' delay projections leave it out until it resumes (§7, §8). Say why in a comment — the pause carries no text of its own. Done and Backlog tasks are never paused: the row is absent for them, and moving a paused task there resumes it. The REST API and MCP carry the same paused flag.
Labels (one shared list per organization), a rich-text description (every edit is narrated in the task's activity feed with before/after excerpts), attachments, comments, a parent, subtasks, and links to other tasks ("blocks", "is blocked by", "relates to") — relations may span projects and teams.

Creating a task#

New task (a board column's +, the + beside a swimlane's or a side-board's name, or the action on an empty board) opens a short dialog with Project, Sub-project, and Title. The title is focused and required; click Create or press Enter in the title to create the task and open its usual task window. Add the description, assignee, priority, remaining hours, dates, attachments, and relationships there, using the same controls as when you edit an existing task.

The dialog starts on the project or sub-project you opened it from. Change Project to update the Sub-project list. Both lists offer only writable destinations, and projects without sub-projects are omitted. If you create outside the current scope, the view moves to the task's sub-project. A toast names the new task ID, and the opened task window has its normal shareable URL. New tasks start unassigned with Low priority. A status column's + supplies that column's status; other New task entry points start in Backlog. A task created in the In Review column starts with the project's review time as its Remaining (§7).

All projects / My view board columns have no + because they name no project to create in; use a project or sub-project heading's + instead. On phones, New task also opens this project/sub-project picker. Creating a subtask, linked task, or parent from a task's relationship picker keeps its existing quick-create flow. Moving an existing task still uses Move, which preserves its ID.

Permanent task IDs#

Tasks are numbered QN-1, QN-2, … from one counter per organization, assigned by the server at creation and never changed or reused. Moving a task to another sub-project or another project keeps its number and its labels. Copied links, commit messages and automation references never dead-end.

✦ What sets this apart — In Jira, moving a task can renumber it; in Linear, keys are per-team. In Qivo a task reference is permanent for life, so reorganizing your projects never breaks a single link.

Archiving a project — putting a finished one away#

A project that is over should leave the sidebar without taking its record with it. Project settings → Danger zone → Archive project does that. It sits above Delete, and it is the one of the two you can take back.

The project leaves the sidebar, the scope pickers, the Overview, the Board, the Roadmap and the capacity plan, together with its sub-projects. Nothing is deleted: every task, comment, attachment, estimate and history entry stays exactly as it was.
Its data stops being loaded. This is the part you feel: an archived project's tasks are not fetched at all, by any of your clients, so the app carries only the work you are actually doing. It is also why an archived project takes no new tasks — restore it first.
Settings → Projects → Archived projects lists everything that has been put away, newest first, with Restore and Delete on each row. Restoring brings the project, its sub-projects and all of their tasks straight back. Deleting is the permanent one, and it is still two clicks.
Archiving and restoring take the project's lead — the same right that deletes it, which org admins and the project lead already hold.
Sub-projects archived with a project come back with it, and are shown on its row as chips rather than as separate entries. A sub-project you archive on its own stays behind when its project returns, and then gets a row of its own.

✦ What sets this apart — "Archived" here is not a label that hides rows from a list: your browser genuinely stops downloading the project. A ten-year-old organization opens as fast as a ten-week-old one, and the decade is still there, one click away.