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:
- 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:
- 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, whether they were overdue or flagged.
- 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
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
activeand a client statusactiveare different statuses. - Backlog and finished are mutually exclusive. A status is either a not-started queue or a terminal state, 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 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.