Inspection Policies
Organization defaults and project overrides for reinspection rules, evidence on a fail, automatic issues and the reinspection cycle limit.
Inspection policies decide what happens when an inspection fails and comes back for another round. Open Admin → Inspections → Policies in the sidebar.
Organization defaults and project overrides
The Scope picker at the top of the page has two choices:
- Organization — your house rules. Click Save Defaults to keep them. They apply to every project that has not set its own values.
- Project — values for the project you are in. Click Save Overrides to keep them.
The page opens on Project.
Project overrides only what differs
The Project scope starts from your organization's defaults plus anything this project already overrides. When you click Save Overrides, only the settings that differ from the organization's are saved for this project; the rest keep following the organization. A line at the top says how many settings are overridden, and Use organization values puts them all back — click Save Overrides to keep that.
Reinspection verdict rules
When an inspection is sent back, each party gets a rule for their earlier verdicts. There are three parties: the Performer (the first party), the Checker (the middle parties) and the Approver (the final party).
| Rule | What the party does on the next round |
|---|---|
| Re-do everything | Judges every item again from scratch |
| Re-do failed only | Judges again only the items they failed; passed items carry forward |
| Carry everything forward | Judges nothing again; earlier verdicts carry forward |
Earlier records are kept and stay viewable whichever rule you pick.
Multi-party flow
- Rejections always return to the performer. When a checker or approver fails an item, the inspection goes back to the performer to fix. You cannot turn this off.
- Reviewer Re-Sign-off — Explicit sign-off (all reviewers) makes every reviewer sign off again on each round. Only reviewers with changes skips reviewers with nothing to judge again.
- Auto-Inherit Passed Verdicts for Approver — fills in a pass for the approver on every item all earlier parties passed. It applies only when a separate approver comes after at least one checker. The approver can still change any verdict.
Evidence, issues and limits
| Setting | What it does |
|---|---|
| Require Evidence on Fail | An inspector must attach a photo or document to mark an item as failed. Checklist items set to require evidence always need it, whatever this setting says |
| Auto-Create Issues on Fail | When an inspection fails and goes back to the performer, an issue is raised for each failed item |
| Require Issue Resolution Before Reinspection | Reinspect on a completed inspection is refused while any linked issue is still open. A failed inspection still goes back to the performer straight away |
| Max Reinspection Cycles | How many times an inspection can be sent back. Leave it empty for no limit. Once the limit is reached, sending it back again is refused |
Related
- Reinspection: how a reinspection runs on the inspection itself
- Multi-Party Flow: performer, checker and approver
- Issues: what happens to a failed item once it becomes an issue
Questions
Do changes here affect inspections already running?
Yes. Every inspection on the project uses the current values from its next submit, not the values it started with.
What does Require Issue Resolution Before Reinspection stop?
Reinspect on a completed inspection. While it's on, Reinspect is refused until every issue linked to the inspection is closed, and the button's tooltip says how many are left. It doesn't change a failed inspection going back to the Performer: the Performer can't submit while a linked issue is Open or In Progress, whatever this setting says.
Why does my project ignore a change I made to the organization defaults?
The project has its own value for that setting. The line at the top of the Project scope says how many settings it overrides. Click Use organization values, then Save Overrides.