# Custom fields and statuses

> Shape tasks and workflow to how your team actually works — without creating a form nobody fills in.

> For the complete documentation index, see [llms.txt](https://helpdesk.orangescrum.com/llms.txt).

Source: https://helpdesk.orangescrum.com/guide/cloud/tasks/custom-fields-and-statuses

---
> **Pro and Premium**
>
> Custom fields and custom task statuses require Pro Unlimited or above. See the
> [feature matrix](https://helpdesk.orangescrum.com/guide/cloud/plans/feature-matrix).

## Custom statuses

The default statuses are a starting point. Custom statuses let the board reflect
the stages work genuinely passes through.

### Designing them

**Describe the real path**

    Ask the team to walk a recent task from idea to shipped. The stages they
    name are your statuses — not the ones you wish they used.

**Keep it to five or six**

    A board with six columns is readable. Twelve means horizontal scrolling and
    a board people stop opening.

**Separate waiting from working**

    "In review" and "Waiting on customer" are different problems. If work
    regularly stalls in a state, give it a column — that is where your queue is.

**Define done explicitly**

    Write down what "Done" requires. See
    [checklists](https://helpdesk.orangescrum.com/guide/cloud/tasks/checklists).

> **Renaming a status changes its meaning retroactively**
>
> Historical tasks move with it, so past reports shift too. Get the set right
> before there is much data.

### A workable default

| Status | Means |
| --- | --- |
| **Backlog** | Not started, not committed |
| **To do** | Committed to this sprint or week |
| **In progress** | Actively being worked |
| **In review** | Waiting on someone else |
| **Done** | Meets the definition of done |

## Custom fields

Fields specific to your work — client, environment, release version, component,
severity.

### Add them sparingly

Every field is a tax paid on every task created. Half-filled fields are worse
than no field, because reports built on them are quietly wrong.

> **Tip**
>
> Before adding a field, name the **decision** it informs and the **report** it
> feeds. If you cannot, do not add it.

### Field types

| Type | Good for |
| --- | --- |
| Text | Free-form references — a ticket id |
| Number | Quantities, scores |
| Date | Dates other than start and due |
| Dropdown | A fixed set — environment, severity |
| Multi-select | Several from a set — affected components |
| User | A second person — reviewer, approver |
| Checkbox | A yes/no flag |

> **Prefer dropdowns over text**
>
> A text field becomes "prod", "Prod", "production" and "PROD" within a month,
> and cannot be reported on. A dropdown stays clean.

### Fields versus labels

- **Custom field**: Structured, one value, reportable. "Environment: staging".

- **Label**: Ad hoc, many per task, no structure. "needs-design", "blocked".

Use a field when you will filter or report on it. Use a label when you just need
to mark something.

## Scope

Both can be defined per project, so a client-services project can carry a
"Client" field that an internal project does not.

> **Per-project fields make cross-project reporting harder**
>
> If you want a workspace-wide report on a value, define the field consistently
> everywhere — or it will only cover some projects.

## Automation

Once statuses are meaningful, [automation](https://helpdesk.orangescrum.com/guide/cloud/projects/project-settings#automation)
can act on them — assign a reviewer when a task hits Review, or flag anything
sitting in Blocked for over two days.

Start with one rule that removes real manual work.

- [Next: import and export](https://helpdesk.orangescrum.com/guide/cloud/tasks/import-and-export): Getting data in and out.