Task types

Task types are a separate way to categorize tasks alongside status — they describe what kind of work a task is (billable client work, internal admin, a subtask of something bigger). Beyond name and color, each type carries three flags that shape how it behaves in forms and invoicing. Configure them on the Task types page, where you can create, edit, reorder, or disable types.

Task types share the same configuration system as custom statuses and relationship types — the same editor, ordering, enable/disable, and delete-with-reassign behavior apply.

Fields

Type ID — a short identifier (e.g. billable, administrative) used in exports and imports.
Name — display label.
Description — optional helper text.
Color — optional color for badges.
Order — position in dropdowns.
Enabled — when off, hides the type from pickers but keeps it for tasks that already use it.

Three behavior flags:

Billable — marks tasks of this type as billable. Useful for invoice line items and reporting.
Standalone — when on, the type can be used on top-level tasks. When off, only subtasks can use it.
Embeddable — when on, the type can be used on subtasks. When off, subtasks can't use this type.

Defaults

Three types come ready to use — edit or remove any of them:

Billable — billable, standalone.
Administrative — standalone only.
Subtask — embeddable only.

Custom fields

Each task type can carry its own custom fields — extra text, multiline, or date inputs that appear on tasks of that type. Define and manage them in the type's editor; the full behavior (field types, required toggle, the staged delete with its data-loss confirmation) is covered in Custom fields.

How type options change what you see in forms

Task forms filter the type picker based on what you're creating:

Creating or editing a top-level task — only standalone types appear.
Creating or editing a subtask — only embeddable types appear.

If both flags are on, the type can be picked anywhere. If both are off, the type still exists but won't show in any picker — handy for retiring a type gradually.

Project scope

By default a task type is available for all projects. In the type's editor you can switch off Available for all projects and pick a specific set of projects — the type is then offered only on tasks that belong to those projects. This uses the same "all, or a chosen whitelist" pattern as kanban boards and the calendar filter.

How scoping plays out:

Task forms only offer valid types. When a task is linked to one or more projects, the type picker lists only types in scope for every linked project. A task with no project can use only all-projects types.
Multiple projects need a common type. If a task is linked to several projects, a scoped type must cover all of them. When there is no type that covers the whole set, the type can't be assigned and the form blocks the change with an explanation.
Narrowing scope is guarded. If you remove a project (or switch off all-projects) while tasks in the now-excluded projects still use the type, the save is blocked and a short migration step asks you to reassign those tasks to another type first; it then applies the new scope in one go. Widening scope is always safe.
Bulk edit excludes invalid rows. In a bulk edit, any row whose resulting type isn't valid for its projects is flagged and left out of the save, with a summary of what was skipped.
Kanban offers covered types. A board only offers types available in at least one project it covers; see Task kanban.

Where types appear

As a column on the task list, with a color dot.
As a filter you can multi-select.
On kanban cards — a colored type dot and a $ marker for billable types; see Task kanban.
When adding invoice line items — a line linked to a task whose type is not billable shows an icon saying so. It is a note, not a block: you can still bill it.

Tips and edge cases

Renaming is safe. Tasks refer to the type by its ID, so a rename flows through everywhere.
Disabling a billable type doesn't change past invoices. Line items already attached stay intact.
Subtask-only types are common. Keep the seeded Subtask type for hierarchy use, and add more if you want different subtask types.
Deleting a type in use prompts a reassign. If tasks still use a type you delete, Ceum first sends you to a short step to pick a replacement type for them and Migrate all, then removes the type. Disable instead if you only want to hide it.

On mobile

Not available on the mobile app — manage from the web app.