QQivo

How work is organized

Organization → Project → Sub-project → Task, with every project owned by a team.

  • 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 and the label list.
  • A team (e.g. Development, Marketing) is a permission group that owns projects — not a place you navigate to. It carries the settings its work is measured by (when a task counts as stale, when Done work is archived, the attachment cap, whether new projects track delays) and has a leader who manages its members and settings and creates its projects. How many hours a week someone can be planned for is not among them: that belongs to the person (§10). Being a member of a team is not access on its own; see §12.
  • A project links several sub-projects into one roadmap and board, belongs to exactly one team, and is where people are granted roles.
  • A sub-project is a discipline workstream with its own board — and the only place tasks can live. While a project has no sub-projects the top bar's New task button is disabled and its tooltip says why: "Create a sub-project first — tasks live in sub-projects."

The task#

Every task carries:

  • Status — Backlog, To Do, In Progress, In Review, Done (Linear-style glyphs everywhere).
  • Priority — Urgent, High, Medium, Low.
  • Assignee — one person (or Unassigned) and a read-only Creator, recorded at creation and never editable (it clears only if the creator's member profile is later removed from the organization). The picker offers the people and agents who can actually do the work: someone switched off, or a Viewer (§14), is never on the list.
  • Remaining — hours of work left, 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); the subtask rule above is the one exception, and it clears a 0 exactly as it clears any other value.
  • Due date — the day it must be finished by, at the latest.
  • Planned period — a start → end week pair that puts the task on the roadmap. Qivo plans in whole weeks on purpose (see §6).
  • Labels (one shared list per organization), a Blocked flag with a reason (shown as a red banner with a one-click Unblock; setting the flag is currently an automation-side affair — the REST API and MCP can raise it, the app clears it), 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 (top bar, a board column's +, or a side-board's +) opens a dialog that captures everything in one pass: title, project, sub-project, parent, priority and status segments, assignee, remaining hours, due date, planned period, the same rich-text description editor, and attachments — files stage locally and upload automatically the moment the task exists ("uploaded when the task is created"). Where the task goes is asked in two steps: pick the project, and the sub-project list underneath becomes that project's. It opens on the project you're in — the common case is one glance and past it — but you can change it, so a create started from the wrong board doesn't have to be cancelled and started again somewhere else. Both lists offer only what your role can actually hold a task in — a viewer's projects aren't there — and a project with no sub-project isn't either, having nowhere to put one. (Moving an existing task is still a move, not a re-create: only the Move dialog keeps its ID. And All projects / My view name no project to create in, so their top bar and board columns offer no New task at all — use a side-board's + or open a project first; §3.) Creating keeps you in flow: the dialog closes, a toast names the new key (and the view jumps to the task's project if you created it elsewhere), but the task window does not open — click the new card whenever you want to keep editing.

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 — the Move dialog says it outright: "its ID (QN-x), its labels and any links to it are permanent." 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 owning team's leader 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.