Custom statuses, task types, and relationship types are all built on one shared configuration system, and they all follow the same deletion rule: a configuration nothing points at is deleted after a confirmation, and a configuration something still points at is not deleted at all until those records have been moved somewhere else.
Moving them is a separate screen — a reassignment step at /settings/entity-config-migration/<id>, reached from the settings page for that configuration. It is the only way a status or type in use can be retired, and it is refused server-side as well as in the app, so the same rule applies to the MCP tools and the CLI.
What sends you there
Any configuration card that records point at shows an in-use marker naming the count, worded for its own kind — Used by 3 clients, Used by 12 tasks, Used by 4 relationship links. From there:
- Delete on that card opens a dialog: "Status in use", naming the configuration and the count, with a Reassign button. Confirming opens the reassignment screen. Cancelling leaves everything as it was.
- Reassign, the action beside the usage marker, goes straight to the same screen without asking first.
Deleting a configuration nothing uses never goes near this screen — it is a plain confirm-and-delete.
What counts as being in use
The count is of the records that name the configuration, not of everything nearby:
- A status — the records of its own kind that carry it: clients, projects, top-level tasks, or invoices. Task statuses count top-level tasks only, because a subtask takes its parent's status and carries none of its own.
- A task type — every task carrying it, subtasks included. A subtask does carry its own type.
- A relationship type — the link rows using it, project-to-project or task-to-task. The projects and tasks at either end are untouched by this; what is counted is the links between them.
Selecting the usage marker opens a list of exactly those records, paged, with a link to each. A relationship row names both ends, since a link is not "used by" a single record.
What the screen asks
The page is a single choice:
- Current status (or Current type) — the configuration you are replacing, shown as the badge it renders as everywhere else, with its in-use count beside it as a link to the same usage list.
- New status (or New type) — a picker of every other enabled configuration of the same kind and scope. Disabled ones are never offered as a target, and neither is the configuration being replaced.
Then two buttons: Cancel, and a reassign button carrying the count — Reassign all (12). The reassign button stays inert until a replacement is picked.
What happens to the records
Choosing a replacement and confirming rewrites every counted record to point at it, in one transaction — either all of them move or none do. Nothing else about those records changes: a client keeps its follow-up date, a task keeps its own type and its projects, a relationship keeps its direction, its source, and its target. Only the configuration each one points at is different.
A toast confirms what moved ("Reassigned 12 tasks") and you are returned to the settings page you started from. Lists, boards, and detail pages pick up the new label immediately.
Reassigning does not delete anything. The screen leaves the original configuration in place, now with nothing on it, and you delete it from the settings page as a second, separate step. That is deliberate: it also lets you empty a configuration you want to keep for later, or empty one and then simply disable it instead.
Cancelling
Cancel — and the Escape key — go back without writing anything. The reassignment happens only when you press the reassign button, so leaving the screen at any earlier point leaves every record on its original configuration, which therefore still cannot be deleted.
When there is nowhere to reassign to
The screen needs a target. If no other enabled configuration of that kind exists, it says so — "No other enabled statuses available to reassign to." — and offers only Go back. Enable a disabled one, or create a replacement, and start again.
A related guard sits on the settings page: the last enabled configuration of its kind can never be deleted, whether or not anything uses it. At least one has to remain for new records to use. Disabled configurations do not count towards that.
Narrowing project scope is a different step
Task statuses and task types can be limited to a set of projects. Tightening that scope while tasks in the excluded projects still use the configuration triggers its own, smaller flow: a dialog on the settings page rather than this screen. It asks for a replacement for just the tasks the new scope would strand, then reassigns them and applies the new scope together, so the configuration is never left holding tasks it is not valid for.
Tips and edge cases
- Reassigning a task type respects the embeddable flag. Moving tasks onto a type that is not marked embeddable is refused when any of them is a subtask — pick an embeddable target, or promote those subtasks first.
- Disabling is usually what you want. A disabled configuration disappears from pickers while records already using it keep it, with no reassignment involved. Delete when you want the configuration gone; disable when you only want to stop offering it.
- The counts are live. Records created while you are on the screen are included by the reassignment, which acts on everything pointing at the configuration rather than on a list captured earlier.
- Reassignment is not an undo. Reassigning moves everything currently on a status, not just the records you moved there. Send 12 tasks to another status, change your mind, and reassigning back brings those 12 plus whatever was already sitting on that status — so the second move is wider than the first.
On mobile
Not available on the mobile app — manage from the web app.