How to map a review and resubmit loop
How to map a review and resubmit loop: the comments-and-resubmit pattern behind permits, submittals, RFIs and punch lists, with a cap and escalation. Live building permit example.
A review and resubmit loop sends work to a reviewer, returns comments, and loops until the reviewer is satisfied. Mapping it well means drawing the return path, naming who owns each pass, and deciding what happens when it will not converge.
The short version
- The elapsed time in a review process is in the repeat passes, so draw the return path explicitly.
- Each loop needs a decision, a revise step with an owner, and a defined re-entry point.
- Resubmissions often skip earlier steps: show where the loop rejoins, not just that it does.
- Every loop needs an exit rule: a cap on rounds, a time limit or an escalation.
- The same pattern fits permits, submittals, RFIs and punch lists, so build it once and reuse it.
The loop is the process
Several of the slowest processes in construction share one shape. A building permit application, a submittal, a request for information and a punch list item all go to a reviewer, come back with comments, and are revised and sent again until accepted. The first pass is rarely the problem. The elapsed time lives in the second, third and fourth pass, which is why a chart that shows review as a single box with an arrow out tells you almost nothing about how long the process takes.
Drawing the loop properly takes four things. A decision after the review asks whether there are comments to resolve. A return path leads to a revise step, where someone responds to each comment in writing. The resubmission re-enters the review at the right place, which is not always the beginning. And the loop has an exit rule for when it does not converge: a cap on the number of rounds, a time limit, or an escalation to someone who can decide. Without that, the chart implies the loop always ends, and in practice it does not.
The example below is a building permit application, which shows the pattern twice. Plan review loops through comments until none remain, and later the built work loops through inspection, correction and reinspection. Permit rules, fee structures and review disciplines differ by jurisdiction, so treat the chart as a structure to adapt against your local authority's actual procedure rather than as a description of any particular one.
A permit that loops twice
A building permit from application to certificate. Notice the two places where work returns for another pass.
Getting a complete application in
Preparation, code analysis, forms and fees lead to submission and an intake completeness check. An incomplete application goes back to the form step before any reviewer sees it. This is the first, cheapest loop: catching missing items here avoids a full review round.
Plan review and the comments loop
Complete applications route to the review disciplines, and the code reviewer's output reaches a decision on whether there are comments to resolve. If so, the designer revises the drawings and answers every comment in writing, then the application returns to code review. Drawing the re-entry point matters: a resubmission usually does not go back to intake.
Conditions and issue
With no comments left, fees are calculated and conditions set, and a second small loop checks that fees are paid and conditions met before the permit is issued. Treating this as a decision rather than a step makes the common delay, an outstanding condition, visible on the chart.
Inspection loop and what ends it
During construction, inspections ask whether the work matches the approved plans. A deviation produces a correction notice or stop-work order, the engineer of record assesses and issues a fix, and the work goes back for reinspection. Only a match leads to final sign-off and the certificate. A separate refused path ends the process when a variance is not granted, which is the exit rule for the zoning loop.
How it works
Identify the review and who performs it
Name the reviewer for each pass: the authority, the designer, the owner's representative, the inspector. Put each in their own swimlane in QueryChart so the handoff to and from the reviewer shows up as a lane crossing you can time.
Draw the decision after the review
Add a decision such as 'comments to resolve?' with labelled branches for each outcome. Resist drawing review as a plain step with one exit; the labelled branches are what turn it into a loop and show what happens when the answer is no.
Add the revise step and name its owner
On the comments branch, add the step where someone responds to each comment in writing and revises the work. Put it in the lane of the party that must act. Delay often hides here because the reviewer considers the item returned and the author has not noticed.
Show where the resubmission re-enters
Connect the revise step back to the correct point. A full application may re-enter at review, a punch list item at inspection, a submittal at the reviewer who commented. Pointing the line at the true re-entry step makes visible how much of the process is repeated.
Define the exit rule
Decide what happens if the loop does not converge: a maximum number of rounds, a time limit, or an escalation to a named person. Add it as a decision or an escalation branch. If your contract or authority sets a rule, use it; if not, agree one with the parties and note it in a comment.
Reuse the pattern across processes
Once the loop is drawn well, copy its structure to the other reviews on the project. The same shape appears in /templates/construction-submittal-review-process, /templates/rfi-request-for-information-process and /templates/construction-punch-list-process, with different owners and exit rules.
Mistakes to avoid
A review box with one arrow out
This implies the work passes first time. It makes the process look short and hides the rounds where the time is spent.
Looping back to the start
Sending every resubmission to the beginning exaggerates the repeat work. Draw the real re-entry point, which is usually mid-process.
No exit from the loop
A loop with no cap or escalation suggests every review ends in agreement. Add the rule, even if the rule is only 'escalate to the project manager after the second round'.
Hiding the author's side
If the revise step has no owner, comments sit unanswered. Name who answers and in which lane, so the wait is attributed to someone.
Map your own review loop
Open the building permit example as your own chart, rename the lanes, and add the exit rule your authority or contract requires.
Related guides
Frequently asked questions
What is a review and resubmit loop?
A repeating sequence where work goes to a reviewer, comes back with comments, is revised and goes back for another review. It ends when the reviewer accepts the work or when an exit rule applies. It appears in permit plan review, submittals, RFIs, design reviews and punch lists.
How many rounds should the chart allow?
That depends on your contract, your authority or your own agreement, and this guide does not set a number. What matters is that the chart states a rule, whether it is a number of rounds, a time limit or an escalation, so that nobody assumes the loop ends by itself. Record the agreed rule in a comment on the decision.
Where does the loop re-enter the process?
At the first step that must be repeated, which is often not the start. In the permit example a code comment returns the application to plan review, not to intake, while an incomplete application does go back to the forms step. Check each loop against how the process really works.
Which construction processes use this pattern?
Several. See the submittal flow in /templates/construction-submittal-review-process, the permit flow in /templates/building-permit-application-process, and the RFI flow in /templates/rfi-request-for-information-process. For how these fit together across a whole project, read /guides/how-to-map-a-construction-project-workflow.