A task type classifies a task and defines the structure used for that kind of work. Examples include Task, Bug, Feature, Issue, Request, or a type created for your team's process.Task types are owned by a Space. A task can use only a type from the Space it belongs to.What a task type controls#
Name, description, icon, color, and display order.
Whether it is available for new tasks.
Whether it is the Space default.
Custom fields bound to that type.
One bounded Workflow with an ordered set of statuses and a default status.
Use a separate type when work needs a meaningfully different set of fields or statuses. Use labels for lightweight, combinable classification.Space ownership and defaults#
Each active Space has exactly one default task type. Sharkly uses it when a task is created without an explicit type.The default type must remain enabled and cannot be archived or deleted. Set another enabled type as default before removing the old default from active use.A disabled type remains visible in Space settings but is hidden from the new-task type picker. Existing tasks retain that type.Archiving is a separate soft-delete action. An archived type is hidden from normal settings and pickers, and its name can be reused. Restore it only when its name no longer conflicts with another active type.Bounded Workflows#
Every task type owns one bounded Workflow. The Workflow contains:An ordered list of Organization status definitions.
One default status used for new tasks of that type.
The status names and categories available for explicit writes to tasks of that type.
A status cannot be removed from the Workflow while tasks of that type still use it. Move those tasks to another Workflow status first.Existing data can temporarily contain a status outside a current Workflow after historical configuration changes, but the next explicit status write must use a status in the resolved Workflow.Organization-scoped statuses#
Task status definitions belong to the Organization and can be reused by several task type Workflows in several Spaces.Editing a shared status changes the same definition wherever it is used. When a change should apply only to one task type, create a new status and add that status to the current Workflow instead of changing the shared definition.Organization-scoped custom fields#
Custom field definitions also belong to the Organization. Supported kinds include:Creating a custom field adds it to the Organization library. It appears on tasks only after it is bound to the relevant task types.A binding can be required, ordered, or inactive. Inactive bindings are hidden from task forms and details while existing values are preserved.Removing a binding is different: values for that field are deleted from tasks of the type. Review the affected count before confirming.Change a task's type#
The new type must belong to the same Space and must not be archived.The new type's Workflow governs future status writes.
Custom field values not supported by the new type are deleted.
Values for fields shared by both types can remain.
Choose the new type and status together when the current status is not valid in the new Workflow.Delete a task type#
A task type cannot be deleted when:Existing tasks still use it.
Disable or archive a type when historical tasks must keep it. Delete only an unused, non-default type whose field bindings are no longer needed.Task types versus labels and custom fields#
A task type defines what kind of work this is and controls its Workflow and field set.
A label adds lightweight classification that can be combined with other labels.
A custom field stores structured Organization data and becomes visible through task type bindings.
Modified at 2026-08-04 04:02:55