Task types
A task type describes what kind of work a task represents — a Bug, a Feature, a Documentation update, a Support request, and so on. More than a label, a task type is a template: it decides which custom fields a task carries, and it can even use its own workflow.
Task types are why a bug report and a feature request don’t have to look the same. A bug can ask for “Steps to reproduce” and “Severity,” while a feature asks for “Customer” and “Target version” — because each is a different type with different fields.
What a task type controls
Section titled “What a task type controls”| A task type decides… | Which means… |
|---|---|
| The custom fields on the task | Each type can have its own set of extra fields, bound just to it |
| The workflow (optionally) | A type can follow the project’s default workflow, or override it with its own statuses |
| How the create form looks | When you pick a type while creating a task, the form shows that type’s fields |
Picking a type when you create a task
Section titled “Picking a type when you create a task”When you create a task, choosing its type shapes the rest of the form. Pick Bug and you’ll see the bug fields; pick Feature and you’ll see the feature fields. This keeps each task focused on the details that actually matter for that kind of work, instead of one giant form with empty boxes.
Types and workflows
Section titled “Types and workflows”By default, every task type in a project follows the project’s single active workflow. But a type can override that with its own — useful when one kind of work moves differently from the rest. For example, an Epic (a large body of work) might travel through Planned → In Progress → Shipped, while ordinary tasks use a more detailed set of statuses.
If you’re new to this, don’t worry about overrides yet. Start with the project’s default workflow for everything, and reach for a per-type workflow only when a type clearly needs one. The full mechanics are in Workflows & statuses.