Unified Work Items
Rather than having separate tables for epics, issues, tasks, bugs, and sub-tasks, the PPM module stores all of these in a single Work Item table. A type column distinguishes them. This page covers work item types, keys, and statuses. For how work items are connected to each other, see Hierarchy, Links, and Dependencies.
One table, many types
Every work item has a type field with one of these values:
| Type | Typical use |
|---|---|
| Epic | Large body of work spanning multiple issues |
| Issue | A discrete piece of work (feature, improvement, or requirement) |
| Task | A specific action item, often part of an issue |
| Bug | A defect to be fixed |
| Sub-task | A small unit of work nested under a task or bug |
All five types share the same set of columns: title, description, status, priority, assignees, dates, effort estimate, and so on. This means a single API, a single set of queries, and consistent behaviour across types. Type-specific rules — such as which types can be nested under which — are covered in Hierarchy, Links, and Dependencies.
Auto-generated keys
Each work item receives a human-readable key based on its project's key prefix and a per-project sequence number. For example, if a project has the key prefix WEB, its work items are numbered WEB-1, WEB-2, WEB-3, and so on.
These keys are auto-generated on creation and are unique within a project. They provide a stable, readable identifier that users can reference in conversations, commit messages, and external tools.
Status and status categories
Each project defines its own set of statuses per work item type. This allows teams to customise their workflow — one project might use "Open / In Progress / In Review / Done" while another uses "Backlog / Active / Deployed."
To enable consistent reporting across projects with different status names, every status is mapped to a status category:
| Status category | Meaning |
|---|---|
| To Do | Work has not started |
| In Progress | Work is actively being done |
| Done | Work is complete |
This mapping is configured when statuses are defined. The status category is derived (not stored directly on the work item) and is used for portfolio-level dashboards and metrics — for example, calculating what percentage of a project's work items are complete, regardless of what the individual statuses are called.