Manage a Project
Once a project exists, you manage it from its detail page: edit its details, move it through its status lifecycle, map stock into it, and — if nothing depends on it — delete it.
Editing a project
- Open the project from the Projects list.
- Click Edit (requires the edit project permission).
- Update the header fields — name, location, partnership, dates, custom fields.
- Save. Validation runs on submit, just as it does on creation.
Note: the project code is permanent and can't be changed. Partner holdings are not edited from the main form — they have their own holdings action so the change can be captured for audit (see Partner holdings below).
Status transitions
A project's status follows its lifecycle. From the detail page, change the status to move the project forward — for example Draft → Planning, Planning → Active, Active → Completed, or pause it with On Hold:
On Hold returns to Active when the block is lifted. Completed and Cancelled are end states. The full lifecycle, with meanings, is in the Projects overview and the canonical Status lifecycles reference.
Updating partner holdings
Use the project's holdings action to change ownership. The same rule always applies:
Holdings must sum to exactly 100%, and at least one managing partner is required.
When you save new holdings, the previous set is replaced and the change is recorded in the audit trail. The save is blocked if the total isn't exactly 100.00% or if no managing partner is designated.
Stock mapping and allocations
A project is developed using the stock allocated to it. From the project you can:
- See which stocks are already allocated (and the area each contributes).
- Allocate available stock into the project.
Allocations follow a review workflow — Draft → Submitted → Approved / Rejected → Posted — and only an approval actually consumes the stock's availability. The mechanics, including who approves and how rejections work, are covered in Allocating stock to projects. You can drive allocations from either side: the stock's Allocations section or the project's stock-mapping section.
Deleting a project — guardrails
A project can be deleted only when nothing depends on it. The system soft-deletes it (it's hidden but kept for audit) and removes its partner holdings in the same transaction.
Deletion is blocked when the project still has downstream references — for example:
| The project still has… | Result |
|---|---|
| Subprojects | Blocked |
| Units | Blocked |
| Stock allocations | Blocked |
When a delete is blocked, you get a clear message naming what references the project (for example, "Cannot delete — it is referenced by 3 subprojects") and a suggestion to set the status to Cancelled instead. For the complete list of what blocks deletion across every entity, see Delete guardrails.
If you want a project "out of the way" but it has dependents, cancel it rather than trying to delete it. Cancelling keeps the history intact and removes it from active views.