Reinspection
What happens when an inspection is rejected — clearing rules, cycle tracking, and issue resolution gates.
When any reviewer (Checker or Approver) rejects an inspection, it cycles back to the Performer for reinspection. How much each party must re-judge depends on the reinspection mode configured in your project's Inspection Policies. Previous verdicts, notes, and evidence are always kept for the audit trail and stay viewable in the comparison column — reinspection only decides what must be re-judged, it never deletes records.
When Reinspection Triggers
| Trigger | What Happens |
|---|---|
| Any reviewer fails an item | The inspection goes straight back to the Performer to fix — a Checker's rejection does not move forward to the Approver |
| Approver rejects | Same — cycles back to the Performer |
The reinspection counter increments each time the inspection cycles back.
Re-Judging Modes
Each party role has a configurable mode that determines how much they must re-judge on reinspection. Nothing is deleted — items that must be re-judged are simply shown as pending until the party records a fresh verdict; previous records stay viewable in the comparison column.
| Mode | Effect | When to Use |
|---|---|---|
| Re-do everything | The party re-judges every item from scratch (shown as pending). Previous records kept. | When you want the performer to re-evaluate everything without bias from prior results |
| Re-do failed only | The party only re-judges items they previously failed. Passed/N/A items carry forward. | When you only need the failed items re-checked — saves time on large checklists |
| Carry everything forward | Nothing needs re-judging — previous verdicts carry forward. The party can still update any item. | When you want to keep prior results and selectively update — useful for minor corrections |
Default Configuration
| Party | Default Mode |
|---|---|
| Performer (first party) | Re-do everything |
| Checker (middle parties) | Re-do failed only |
| Approver (final party) | Re-do failed only |
Configure Per Role
Reinspection modes are set in Admin → Inspection Policies and can be configured at the organization level (defaults) with project-level overrides. Each party role has its own setting.
Reinspection Limits
| Policy | Default | Effect |
|---|---|---|
| Max Reinspection Cycles | Unlimited | When set, the Reinspect button is disabled once the limit is reached. A tooltip explains why. |
If the limit is reached, the inspection stays in its current state and cannot be cycled back. This prevents endless inspection loops on problematic items.
Issue Resolution Gate
Open Issues Block Reinspection
When the "Require Issue Resolution Before Reinspection" policy is enabled, the Performer cannot submit their reinspection until ALL linked issues are resolved (Fixed or Closed).
The flow with issue resolution:
- Inspection fails → quality issues created for failed items
- Assignee fixes the defects → marks issues as Fixed
- ALL sibling issues must be Fixed
- Only then can the Performer record reinspection verdicts
- On successful reinspection advancement → Fixed issues auto-close
Issue Rules During Reinspection
- The Performer can only FIX issues — they cannot close them directly
- ALL sibling issues (from the same inspection) must be Fixed before any single issue can close
- Auto-close fires when the Performer advances during reinspection AND all issues are Fixed
The Reinspection Cycle
Next Steps
- Issue Lifecycle — How issues move through their status workflow
- Multi-Party Flow — The sequential review process
- Completed View — What the final outcome looks like