1. task
Sharkly docs
  • Welcome to Sharkly
  • Quickstart
  • agent-and-computer
    • Agents
    • Chat with an Agent
    • Agent task execution
    • Comments and replies
    • Inbox
    • Repositories
    • Skills
    • Crews
    • Computers
  • task
    • Task types
    • Task statuses
    • Task relations
    • Task labels
    • Task subscriptions
  • integration
    • Jira integration
    • Slack integration
  • space
    • Spaces
    • People
    • Tasks
    • Projects
    • Automations
    • Views
    • Sprints
  • cli
    • Sharkly CLI
    • Personal access tokens
  1. task

Task types

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#

A task type includes:
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:
Text.
Number.
Single select.
Multi select.
Boolean.
Date.
Member Picker.
URL.
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.
When the type changes:
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:
It is the Space default.
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
Previous
Computers
Next
Task statuses
Built with