Change reasons
Why locked-sheet edits demand a written reason, and where the reasons live.
When you edit something on a completed sheet or inside a finalised or archived project, the workspace asks you for a one-line change reason before saving. The reason is stored alongside the change in the audit log.
This is the workspace's mechanism for keeping a defensible paper trail when decisions change after sign-off.
When you'll see the dialog
You'll be asked for a reason whenever you edit:
- An item on a sheet that is marked complete.
- An item on any sheet within a project whose status is Finalised or Archived.
- A status change away from Finalised or Archived (e.g. Finalised → Draft).
- An attachment, comment, or note on a locked sheet.
- An undo or redo on a locked sheet. Same dialog as a fresh edit, so the revert still lands a reason on the audit row.
You will not be asked for a reason for any of these:
- Edits while the sheet is in normal "editing" state (not yet marked complete) and the project is Draft or In review.
- Read-only actions (viewing, exporting, copying a link).
- Adding a comment that's purely a discussion, not an edit. (Comments can be added freely; they're separate from item edits.)
Anatomy of a good reason
A change reason is just a short text string, there's no minimum length other than "non-empty", but the trail is more useful with reasons that explain why the change happened, not what changed. Compare:
| Less useful | More useful |
|---|---|
Updated colour | Customer requested matte black after seeing sample |
Fixed it | Supplier discontinued ABC-123, switching to DEF-456 |
… | Site team flagged dimensional clash with HVAC duct |
The dialog itself is identical regardless of which surface triggered it.
Where the reasons surface
| Surface | What you see |
|---|---|
| Audit log | Every locked-edit row shows the reason, the user, the timestamp, and a diff of what changed. |
| Item right-rail | The most recent change reason for that item is summarised in the item's history thread. |
| Exports | Reasons are not embedded in customer-facing workbooks, they live only in the workspace's audit trail. |
Why this exists
In construction, decisions are sequential and binding, once a customer signs off on Plumbing, suppliers are ordered and trades are scheduled around it. When a sign-off is later changed (because of supply issues, customer reconsideration, or site discoveries), it matters who changed it, when, and why. The change-reason flow makes that record automatic instead of reliant on memory or email.
What if you make a typo in a reason
Reasons are immutable once saved, you can't go back and edit one. If a reason is misleading, the standard practice is to make a follow-up edit with a new reason that explains the correction.
Tips for admins
If your team is producing sparse, low-quality reasons, the audit log is the right place to spot the pattern. You can filter by user and review the reasons being given. The dialog enforces non-empty, but quality is a team norm, not a technical constraint.