Custom statuses

You define your own statuses for each kind of record, so every entity can follow a lifecycle that matches how you actually work. Statuses also drive several behaviors elsewhere in Ceum — kanban columns, overdue logic, the alerts page, and client follow-ups.

Statuses, task types, and relationship types are all backed by one shared configuration system, so the editor, ordering, color, enable/disable, and reassign-before-delete behavior work the same way across all three.

Where to configure them

Each kind of record has its own status page, all using the same editor:

• Clients — Client statuses.
• Projects — Project statuses.
• Tasks — Task statuses.
• Invoices — Invoice statuses.

Core fields (all record types)

Every status has:

• Status ID — a short identifier used in exports and imports (e.g. proposal, paid). You can change it, but each one must be unique within its record type.
• Name — the display label.
• Description — optional helper text.
• Color — optional color for badges and kanban columns.
• Order — position in dropdowns, list filters, and kanban columns.
• Enabled — when off, the status is hidden from pickers but kept for records that already use it.

Options per record type

Some flags only matter for certain records:

• Terminal state (projects, tasks, invoices) — marks the status as the end of the line. Each record type words it in its own way, so the toggle is labelled differently depending on which status page you are on:

  Record type	The toggle reads
  Invoices	Settled status
  Projects	Finished status
  Tasks	Resolved status

  It is one setting with one meaning, and it affects:

  • Kanban column visibility for tasks (see Task kanban).
  • Overdue logic — a settled invoice or a resolved task is never overdue.
  • The alerts page — records in a terminal status don't show, whether they were overdue or flagged.
  • Invoices only: moving one into a settled status offers to record the matching income transaction. See Invoicing workflow.

  Client statuses have no terminal-state toggle — they use requires action below instead.

• Backlog (projects, tasks) — marks the status as a low-priority queue. Affects kanban defaults and list-page default filters. It does not exempt anything from alerts: a backlog task past its deadline is still overdue.

• Requires action (clients) — when a client is set to this status, its next follow-up date is filled in automatically based on action days.

• Action days (clients) — how many days from today to schedule the follow-up.

• Action suppression (clients) — silences the follow-up alert even after the date has passed. Use it for terminal statuses like "Lost" so they don't keep nagging the Alerts page.

Defaults

Each record type starts with a sensible set you can edit, reorder, recolor, rename, or disable:

• Clients — Prospect, Contacted, Discovery, Active, Completed, Inactive.
• Projects — Backlog, Proposal, Active, Delivered, Closed.
• Tasks — Backlog, Todo, Planning, In Progress, Review, Done.
• Invoices — Draft, Sent, Paid.

These defaults come from your starter template and are seeded once, when your account is created. Ceum never re-applies them afterwards: a default you delete stays deleted, and a status you rename, recolor, or reorder keeps your version. The only things that bring defaults back are your own explicit actions — Restore defaults on a status list, switching your starter template, or resetting all your data.

Project scope (task statuses)

Task statuses can be restricted to specific projects. By default a task status is available for all projects; in the status editor you can switch off Available for all projects and choose a project whitelist, so the status is offered only on tasks in those projects. (Client, project, and invoice statuses are always global — only task statuses are project-scopable, since only tasks belong to projects.)

• Task forms only offer valid statuses. A task's status picker lists statuses in scope for every project the task is linked to; a task with no project can use only all-projects statuses.
• Multiple projects need a common status. A scoped status must cover all of a multi-project task's projects. With no common status the change is blocked with an explanation.
• Narrowing scope is guarded. Removing a project (or switching off all-projects) while tasks in the excluded projects still use the status blocks the save and prompts a short migration to reassign those tasks to another status first, then applies the new scope. Widening is always safe.
• Bulk edit and kanban respect scope. Bulk edits skip rows whose status isn't valid for their projects (with a summary), and a kanban board only shows status columns available in at least one project it covers.

Workflows

Add a status

Open the record type's status page, add a row, fill in name and color, pick the right flags, and save. The new status is immediately available everywhere it's used.

Rename a status

Edit the name. Records refer to the status by its ID, not its name, so renames don't break anything — the new name reflows through every place the status appears.

Reorder

Drag rows into the order you want. Kanban columns and dropdowns pick up the new order.

Disable a status

Turn the Enabled toggle off. Records already in that status keep it; the status simply disappears from pickers.

Delete a status

A status no record uses is removed after a confirmation. A status records still use cannot be deleted until those records have been moved onto another status — deleting it opens the reassignment screen instead. See Reassigning records when deleting a status or type. One count is particular to statuses: a task status counts only top-level tasks, since a subtask takes its parent's status. And whatever the usage, the last enabled status of a record type can never be deleted — at least one has to remain for new records.

Tips and edge cases

• Status IDs are scoped per record type. A project status active and a client status active are different statuses.
• Backlog and the terminal state are mutually exclusive. A status is either a not-started queue or the end of the line, never both. Switching on the second flag shows a warning in the status editor's Behavior section, and the save is blocked until you turn one off.
• Default status. New records pick the first enabled status if you don't choose one.
• Mark exactly one terminal status per record type so overdue logic works as expected. Ceum doesn't enforce this, but the alerts and overdue behavior assume it.

On mobile

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