Custom statuses

Define your own status sets for clients, projects, tasks, and invoices, each with flags like finished, backlog, and requires action.

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 delete-with-reassign behavior described here 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:

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:

  • Finished (projects, tasks, invoices) — marks the status as a terminal/done state. It affects:
    • Kanban column visibility for tasks (see Task kanban).
    • Overdue logic — a finished invoice or task is never overdue.
    • The alerts page — finished items don't show.
  • Backlog (projects, tasks) — marks the status as a low-priority queue. Affects kanban defaults and list-page default filters.
  • 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.

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

Delete a status you no longer want. If no records use it, it's removed after a confirmation. If records still use it, Ceum first sends you to a short reassign step — pick a replacement status for every affected record, then Migrate all to move them over before the status is deleted. Nothing is left pointing at a status that no longer exists.

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 finished aren't exclusive. Both can be true on the same status, though that's an unusual combination.
  • Default status. New records pick the first enabled status if you don't choose one.
  • Mark exactly one finished 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.

Open in app

Related articles