N/A is an OUTCOME, not an edit. The checkpoint keeps its frozen label on the checklist, is excluded from the completion denominator, is hidden from the customer, and records who marked it and optionally why.
Also called: N/A · this doesn't apply to this job · no garage doors on this one · skip a checklist item
- 1The confirm dialog explains the consequence and takes an optional reason
- 2The server RPC sets na_at / na_by / na_reason and re-evaluates whether the stage just completed
- 3The N/A overlay is applied LAST when resolving checkpoint state and it WINS — it clears `completed`, because a checkpoint is exactly one of done / not-applicable / outstanding
- 4stageProgress() excludes N/A from the denominator entirely — it does not count as done and it does not block the stage
- 5Marking the last outstanding item N/A can itself complete the stage; the server decides that, not the client
A job's checklist locks when the build starts, so a checkpoint that does not apply to this particular building can no longer be deleted — and a job with no garage doors would have had a garage-door box holding its stage open forever, blocking the customer's stage-complete email and the next stage's start. Marking a checkpoint not applicable is the way out, and it is recorded as an outcome rather than an edit, so the record still shows what was on the list and what was decided about it.
- Stages that can never complete because of an irrelevant checkpoint
- Builders deleting checklist items to get around it and losing the agreed scope
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →