Custom Statuses

Mosic lets every workspace define its own workflow statuses instead of a single fixed “To Do / In Progress / Done” set. You can add, rename, recolor, reorder, and remove statuses to match how your team actually works. Because each status carries a hidden semantic type (not started, in progress, done, on hold, or blocked), the underlying logic keeps working. Completion detection, blocking, and dependencies all stay accurate even if you rename “Completed” to “Shipped”.

Understanding Statuses

A status is the combination of three things:

• Title — the label you see everywhere (for example, “Backlog”, “In Progress”, “Shipped”)
• Color — the color used in badges, the status picker, and the board view
• Type — one of five semantic categories that drives background logic

The Five Status Types

Every status you create belongs to one of these five types. The type is what makes the status meaningful; the title is what makes it readable.

The first three types — Not Started, In Progress, and Done — are required: every status configuration must contain at least one status of each. On Hold and Blocked are optional but recommended for teams that frequently pause or get stuck.

Why Types Matter

The type — not the title — is what drives:

• Whether the Done checkbox on a task is on or off (any status typed as Done keeps the checkbox checked)
• Whether a task is treated as complete in dashboards, filters, and reports
• Whether a task counts as “blocked” in workflows and bulk actions
• Which status changes trigger customer-facing email notifications

This means you can rename statuses freely without breaking any of Mosic’s underlying logic.

Default Status Set

Every new workspace starts with a built-in set of eight statuses. This set is applied to projects, task lists, and tasks automatically.

Existing workspaces were migrated to this set automatically. If you reset a configuration to defaults, you return to this set.

Where Statuses Are Configured

Statuses are configured inside the Settings panel of each parent document. The editor is the same on every level, but the tabs it shows depend on the level you are at.

The editor hides itself while the parent document is still being saved or is in a placeholder state, so you only see it on real, persisted records.

A small resolution source pill appears at the top of the editor. It shows where the active configuration currently comes from — see How Statuses Cascade.

How Statuses Cascade

A status configuration is inherited downward through the hierarchy. The first non-empty configuration in the chain wins.

For example, when a task needs to know its status options, it looks here in order:

1. The task’s task list
2. The task list’s project
3. The project’s space
4. The workspace’s default statuses
5. The built-in default status set

If no configuration is set anywhere in the chain, the built-in default set is used.

The Resolution Source Pill

The pill at the top of the editor tells you exactly where the current configuration is coming from. There are four possible labels:

Hover any pill to see the tooltip Where this configuration comes from.

When you see any non-custom source (inherited from a parent, workspace defaults, or system defaults) and you have permission to edit, an amber button labeled Customize at this level appears. Click it to copy the inherited configuration down to your level so you can start making changes without affecting the parent.

Adding a Status

Before you begin: You need Admin or Editor role on the parent document. Workspace defaults require Admin role specifically.

1. Open the settings panel of the parent you want to configure (workspace, space, project, or task list).
2. Find the Status Configuration section.
3. At the top right, click Add status.
4. Type a name in the New status name field.
5. Pick a color from the 19-color swatch row.
6. Pick a type from the Type row.
7. Press Enter or click Save.

The new status appears at the bottom of the list. You can reorder it later by dragging the handle on the left of the row.

A live preview badge updates as you type and change settings, so you can see exactly how the status will look.

Editing a Status

You can rename any status, change its color, or change its type without breaking anything.

To edit a status:

1. In the editor, find the status row.
2. Click the pencil icon on the right of the row.
3. Change the title, color, or type.
4. Press Enter or click Save.

To reorder a status:

• Drag the handle on the left of the row to a new position.
• Or focus the drag handle and use the arrow keys to move it up or down.

The new order is saved automatically. Reordering is silent — no toast appears.

What Happens When You Rename a Status

Renaming a status auto-updates every existing task, task list, or project that used the old title. You do not need to re-tag anything by hand. Because the underlying type does not change, all the logic that depends on the type (done detection, blocking, notifications, dependencies) keeps working unchanged.

What Happens When You Change a Type

Changing a status type is also safe. For example, if you change “Cancelled” from Done to On Hold, tasks currently using it will no longer count as completed in dashboards. The change is durable and immediate.

Deleting a Status

To delete a status that is in use, you must first choose a replacement. Without one, every task currently sitting in “In Progress” would become orphaned.

To prevent this, Mosic asks you to choose a replacement status. Every existing item using the deleted status is moved to the replacement automatically.

To delete a status:

1. In the editor, find the status row.
2. Click the trash icon on the right of the row.
3. The dialog title is Delete “Title” (no question mark).
4. Pick a replacement from the Move items to dropdown. The replacement must be different from the status you are deleting.
5. Click Delete and move.

Mosic applies the replacement to all affected items in the same transaction. Nothing is lost.

If a level has no statuses you can use as a replacement, you cannot delete the status from there. Add a new status first, then delete the old one.

Customizing at a Specific Level

When the resolution source pill says Inherited from…, you are looking at a configuration that belongs to a parent. You cannot edit it directly — any change would affect every sibling that inherits from the same parent.

To start a configuration of your own at this level:

1. Open the editor where you see the inherited source pill.
2. Click the amber Customize at this level button.
3. Mosic copies the configuration down to your level as a starting point.
4. The pill changes to Custom.
5. You can now add, rename, recolor, reorder, or delete statuses here without affecting the parent.

You can also customize from the system-default state. A level with no custom configuration shows the built-in eight-status default set with a System defaults pill. If you have permission to edit, a Customize at this level button appears in the header — the same button shown for any inherited configuration.

Resetting to Defaults

If you want to throw away your custom configuration and start from the built-in default set, use Reset to system defaults.

Before you begin: This action replaces all statuses at the current level with the built-in default set. Items using a status that does not exist in the default set are reassigned to a replacement — the first Not Started status, which is Backlog in the default set.

To reset:

1. Open the editor at the level you want to reset.
2. Scroll to the bottom.
3. Click Reset to system defaults.
4. Confirm by clicking Reset in the dialog.

Mosic replaces the configuration with the eight built-in statuses. The reset is logged to the activity feed.

Required Status Types

Every configuration must contain at least one status of each of the three required types: Not Started, In Progress, and Done. The editor shows a coverage indicator below the list (above the Reset to system defaults button):

• All mandatory types covered — green check; your configuration is valid
• Missing required types: Not Started, In Progress — red warning; the configuration cannot be saved until you add the missing types

The two optional types — On Hold and Blocked — are not required, but adding them is recommended for teams that pause work or get stuck.

Other rules the editor enforces:

• No blank titles or whitespace-only titles
• No duplicate titles
• Every status has a title, a color, and a type (the editor assigns gray until you pick a color)

Collaboration and Real-time Updates

Status changes are synced to everyone in the workspace in real time. When you save a configuration, every other member with the editor open sees the change immediately. You do not need to refresh.

Concurrent Edit Conflicts

If two people edit the same configuration at the same time, the second save is rejected. The second editor sees a dialog titled “Someone else updated this configuration” with two lists — Your version (your edits) and Their version (the saved version) — and three options:

• Keep my changes — refresh to the latest version, then re-submit your edits
• Use their version — discard your edits and load the current version
• Cancel — close the dialog without saving

Only Keep my changes is fully functional today. The other two options are still in development: the Their version panel currently does not show what changed, so you cannot see what you would lose. If you see this dialog and want to preserve your edits, choose Keep my changes.

Activity Log

Every save, delete, or reset creates one activity log entry on the parent document. The entry records the kind of change (added, renamed, deleted, recolored, type changed) and who made it. Status configuration changes also appear in the parent’s regular activity timeline.

Permissions

Workspace defaults require Admin role (or the workspace owner), even though Editors normally have write access to the workspace. This is a special rule for workspace-level defaults.

Members can edit task-list-level configurations because they have update permission on task lists. They cannot edit space, project, or workspace-level configurations.

When you do not have permission to edit, the editor shows the configuration in read-only mode. You can see all statuses, types, and colors, but the Add status, edit, delete, and reset buttons are hidden.

The Color Picker

The editor offers a fixed palette of 19 colors. The same palette is used for every workspace, so the colors you see in the picker are the colors you can choose from.

The 19 colors are: slate, gray, red, orange, amber, yellow, lime, green, emerald, teal, cyan, sky, blue, indigo, violet, purple, fuchsia, pink, rose.

When you click Add status, the new status starts with the color gray and the type Not Started. You can pick any of the 19 colors regardless of type. A small colored dot appears next to each type label. The colors are recommended defaults: gray for Not Started, blue for In Progress, amber for On Hold, red for Blocked, and green for Done. The dot does not change the status’s own color.

Best Practices

Keep the Configuration Simple

Most teams do well with five to ten statuses. A short list is faster to scan, easier to teach, and reduces the chance of misclassification.

Define at the Highest Shared Level

If every project and task list in your workspace uses the same workflow, configure it once at the workspace level. Each lower level can override it if needed.

Always Include Done-Type Statuses

Statuses typed as Done are what make the Done checkbox and completion tracking work. Even if your team thinks of “Cancelled” as something different from “Completed”, mark both as Done type so completion tracking stays accurate.

Use On Hold and Blocked Differently

• On Hold is for work you chose to pause
• Blocked is for work that cannot proceed because of an external dependency

Marking a status as Blocked (rather than On Hold) changes how it appears in bulk actions, dashboards, and dependency workflows.

Avoid Renaming Mid-Workflow

Renaming a status auto-updates every item using it, which is safe — but it can catch teammates off guard. Communicate a rename before applying it to a configuration that is in heavy use.

Reset Before Deleting Work

If you are cleaning up a configuration that has been customized a lot, Reset to system defaults is a faster way to start over than deleting statuses one by one.

Troubleshooting

I can’t edit workspace defaults

Workspace defaults require Admin role on the workspace. Ask your workspace admin to make the change, or have them grant you Admin role. Editors can edit other workspace settings, but workspace defaults require Admin role.

The editor is empty

A level with no custom configuration shows the built-in default status set with a System defaults pill at the top. If you have permission to edit, click Customize at this level to copy the configuration down. If you do not have permission to edit, the editor is read-only and shows the inherited configuration.

My save failed with a conflict message

Another user edited the configuration while you were making changes. The dialog “Someone else updated this configuration” opens. Choose Keep my changes to re-apply your edits on top of the latest version. If you choose Use their version or Cancel, your edits are lost.

A status I expected is missing from the picker

Possible causes:

• The status exists at a different level of the hierarchy. Check the resolution source pill — if it says Inherited from…, the configuration is coming from a parent.
• The status was deleted. Check the activity log on the parent document to see when.
• The status is part of a configuration that has been reset to defaults.

I renamed a status and now the type seems wrong

Types are not changed when you rename. If a status used to be typed as Done and the Done checkbox is still driving completion, the rename was successful and the type is unchanged. If you want to change the type, edit the status and pick a new type from the Type row.

Tasks are showing the wrong status after a change

If a parent configuration was reset, or a status was deleted with a replacement, some tasks may have moved to the replacement status. This is by design — the alternative is orphaned tasks. Check the activity log on the parent document to see which action moved the tasks.

The editor does not appear

The editor hides itself while the parent document is in a placeholder or unsaved state. Save the parent document first, then reopen the settings panel.

Related Documentation

• Tasks — How statuses appear on individual tasks
• Lists — How statuses apply to task lists
• Projects — Project-level status configuration
• Permissions & Roles — Understanding who can edit what
• Settings — Workspace and document settings pages