# Project settings

> Members, statuses, custom fields, notifications and the rest of a project's configuration.

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

Source: https://helpdesk.orangescrum.com/guide/cloud/projects/project-settings

---
Open a project and go to its settings. What you see depends on your
[plan](https://helpdesk.orangescrum.com/guide/cloud/plans/feature-matrix) and role.

## General

| Setting | Notes |
| --- | --- |
| **Name** | Safe to change at any time |
| **Short name** | Prefixes task references — changing it invalidates references already shared |
| **Description** | Worth filling in: it is where new joiners look first |
| **Type** | Groups projects in portfolio views |
| **Status** | Started, Hold, Stack, Completed |
| **Start / end date** | Feeds Gantt, calendar and portfolio views |

> **Think twice about the short name**
>
> `WR-142` may already be written in commit messages, tickets and chat threads.
> Renaming makes those references dead ends.

## Members

Add and remove people, and set their project-level role.

> **Tip**
>
> On Pro and above, add [teams](https://helpdesk.orangescrum.com/guide/cloud/admin/teams-and-business-units)
> rather than individuals. Membership then follows team changes automatically
> instead of needing a manual edit per project.

## Statuses 

Define the columns work moves through. The defaults are a starting point, not a
prescription.

**Match your real workflow**

    If work genuinely waits in code review, add a **Review** status. Statuses
    that mirror reality get used; aspirational ones get bypassed.

**Keep the list short**

    Five or six columns fit on a board. Twelve produce horizontal scrolling and
    a board nobody reads.

**Define 'done' explicitly**

    The single most common source of disagreement. Write it in the project
    description.

See [Custom fields and statuses](https://helpdesk.orangescrum.com/guide/cloud/tasks/custom-fields-and-statuses).

## Custom fields 

Add fields specific to this project — client name, environment, release
version, component.

> **Every field is a tax on task creation**
>
> Each one is another thing to fill in, and half-filled fields are worse than no
> field because reports quietly become wrong. Add a field only when you can name
> the decision it informs.

## Automation 

Rules that fire on events — assign a reviewer when status becomes Review, notify
a channel when a blocker appears, set a due date when work starts.

Start with one rule that removes real manual work, and watch it for a week
before adding more. Automation that surprises people gets switched off.

## Notifications

Control what the project generates. Defaults are chatty by design.

- **Tune per project**: A high-traffic project should be quieter than a critical one.

- **Let people opt in**: Watchers subscribe themselves to what they care about.

## Budget and cost 

Set a project budget, default hourly rates and cost approval thresholds. Feeds
[Budget and cost](https://helpdesk.orangescrum.com/guide/cloud/time/budget-and-cost) reporting.

## Integrations 

Connect this project to a Git repository, Azure DevOps or Google Calendar. Set
up per project, not globally, so each links to the right repo. See
[Integrations](https://helpdesk.orangescrum.com/guide/cloud/integrations/overview).

## Archiving and deleting

Set status to **Completed** to archive. Keep the data — it feeds historical
reporting and makes future estimates better.

> **Deletion removes everything**
>
> Tasks, comments, attachments and logged time, permanently. Export first if
> there is any doubt.

- [Next: project templates](https://helpdesk.orangescrum.com/guide/cloud/projects/project-templates): Stop configuring the same project twice.