A reviewer returns a package for revision while the required-on-site date stays fixed. Your submittal log should show the current revision, the next person responsible, and whether the remaining review and delivery periods still fit. Keep a stable item ID across revisions so the returned package remains traceable after its replacement is submitted.
Copy the fields below into a spreadsheet or your designated project register. Maintain one current-item view and preserve a separate revision history (including the files and responses behind each row). This is an in-page working template, not a software comparison or a promised download.
Copyable fields for the current-item register
Start each current-item row with the same fields, even when some values are unknown. Use a date format your team can sort and a controlled status list the project owner has defined. Record the source and owner of an assumed lead time instead of treating a blank as zero days.
Identity: Project ID [ ]; submittal ID [ ]; specification section [ ]; item title [ ]; type [product data / shop drawing / sample / other]; responsible contractor [ ]; submittal manager [ ]; current revision [ ]; current controlled attachment [ ].
Required dates: Required-on-site date [ ]; source schedule activity and revision [ ]; procurement or delivery lead time [duration and calendar basis]; lead-time source and checked date [ ]; planned final return date [ ]; planned design-review start [ ]; planned internal-review start [ ].
Current review: Status [ ]; current responsible person [ ]; current submission date [ ]; response due date [ ]; actual response date [ ]; exact review disposition [ ]; response attachment [ ]; next action [ ]; next-action owner [ ]; next-action due date [ ].
Release and delivery: Distributed revision [ ]; distribution date and recipients [ ]; procurement authorization reference [or unresolved]; supplier-confirmed dispatch [ ]; supplier-confirmed arrival [ ]; actual receipt [ ]; latest update [date and person]. Keep an unconfirmed date labeled as an estimate.
Revision-history row, repeat for every review cycle: Project ID [ ]; submittal ID [ ]; revision [ ]; submitted file and date [ ]; reviewer [ ]; response and date [ ]; response attachment [ ]; next revision [ ]; superseded by [ ]; distribution record [ ].
Work backward from the required delivery date
Procore’s submittal creation documentation distinguishes required-on-site date, lead time, internal review, design review, and planned return. Its documented schedule calculations use calendar days when the feature is enabled. For your register, state whether each duration uses calendar days or an approved work calendar before subtracting dates.
Use the required-on-site date to calculate the latest supported final return date after allowing the procurement and delivery period. Work backward through design review and internal review to the initial submission needed. Confirm the sequence with the people doing the work: manufacturing that starts only after a release needs a different assumption from stock that can ship once the order is placed.
In a hypothetical calendar-day plan, material must be onsite December 21, 2026. Assume 28 days from accepted return and authorized supplier release to delivery, 14 days of design review, and 7 days of internal review. The supported dates are November 23 for final return, November 9 for design-review start, and November 2 for internal-review start. These are example planning assumptions, not contractual review entitlements or supplier commitments.
The baseline includes no resubmission allowance, holidays, or contingency. If those affect the job, the owner must revise the durations or initial submission date. A row can show a response due before the required-on-site date and still be too late, because the material needs its remaining procurement period after review.
Follow a returned package through its next revision
Assume the hypothetical item is control panel CP-01 on project J-214, submittal 230900-01. The responsible contractor submits revision 0 to design review on November 9. The response on November 16 requires revision to the panel identification schedule. Keep that response, identify the next responsible person, and create revision 1 rather than replacing the old file.
| Revision | Design submission | Response date | Review disposition | Next action | Current response target |
|---|---|---|---|---|---|
| 0 | November 9 | November 16 | Revise and resubmit | Contractor prepares revision 1 | Superseded by revision 1 |
| 1 | November 18 | Pending | In review, no disposition yet | Assigned reviewer responds | November 23, pending reviewer confirmation |
The November 23 target leaves a five-calendar-day window after revision 1 is submitted. It is a requested recovery date in this example, not a promise that the reviewer can meet it. The project engineer must confirm the review plan and the supplier’s delivery basis. If the review cannot finish by that date, the log should expose the resulting delivery risk without inventing an approved acceleration plan.
Keep the current-item view on revision 1, with its pending response and current owner. Preserve revision 0 in the history with the returned markup. A count of open submittals can use current item IDs, while a review-workload count can use individual revision cycles; label the basis so resubmissions cannot inflate the number of distinct items.
Separate review disposition from logistics
Preserve the reviewer’s exact disposition and map it to your reporting status through an owner-approved rule. A label such as reviewed with comments can require action under the project’s procedures; a generic closed label does not establish what may proceed. Keep the comment attachment available to the people responsible for implementing it.
Submission, review completion, procurement release, shipment, and receipt describe different events. Record a procurement authorization reference and a supplier-confirmed date rather than turning a favorable review into an automatic order or delivery. If the supplier changes its lead time, preserve the old assumption and update the forecast date with the source of the change.
Use the construction purchase order software comparison when the handoff needs a purchasing record. Keep a controlled link from that record to the relevant submittal revision, so the order does not refer to an obsolete product configuration. The submittal review record alone should not be treated as a spending authorization.
Review dated exceptions and their next owners
Filter the current-item register for missing reviewer assignments, expired response targets, and forecast return dates later than the supported procurement-release date. Include missing lead-time evidence as an exception. A row with no lead time should not pass the date check because the spreadsheet formula treats an empty cell as zero.
For each exception, record the constraint and the next action: a reviewer confirms a date, the contractor prepares a corrected package, or procurement obtains a supported lead time. The construction scheduling software comparison addresses the separate task of maintaining project dependencies. A log highlights the record needing attention; the schedule owner decides the effect on the project plan.
Save a dated snapshot before the coordination meeting, then record decisions and changed assumptions after it. This lets the next meeting distinguish a newly late item from an item whose target was moved. Keep superseded files accessible under the project’s permissions while marking the current distributed revision so field recipients do not have to infer which attachment governs.
Where Permute fits in a cross-project submittal review
Permute sells the context layer between connected business records and AI tools. We can scope a cross-project view using permitted submittal exports, an Excel delivery register, and supporting records in Google Drive. Match project and item IDs while preserving revision references, rather than merging packages because their titles resemble each other.
We apply declared definitions of current item, pending review, and unsupported delivery date to those inputs. A project leader can ask Claude or ChatGPT which delivery assumptions lack evidence and inspect the permitted records behind the answer. Source refresh and missing response attachments should remain visible so an old export cannot appear to be a current review.
Explore the records behind a submittal exception
Start with a permitted current-item register and the revision history for one package.
Keep technical acceptance and procurement authority separate
We are not a forecasting engine and do not decide technical acceptance, contractual review periods, or authorization to procure. This reporting workflow reads permitted inputs; it does not issue a reviewer’s response, order materials, or write back into the project system. No native connection to a construction product is promised here.
A static template also depends on people updating its dates and file references. If that operating burden becomes the constraint, the submittal software comparison evaluates review routing and resubmission tools. Keep a working register when it can preserve the required history and responsibilities; a software purchase is not required to use these fields.
Keep delivery needs attached to the review history
A submittal log should connect a stable item to its current revision, review responsibility, and supported delivery plan. Work backward from the required-on-site date using stated durations, then expose the difference when a review or supplier assumption changes. Preserve returned packages and their responses instead of replacing the evidence. Keep procurement authorization and actual receipt separate from the review result.
Review a submittal-to-delivery handoff
Bring one returned package, its current revision, and the delivery assumptions to examine where the dates no longer align.
Questions about submittal log
Should a package have one row or several?
Choose a stable item or package level that matches the project’s review process. Keep separate records when components have different reviewers, dispositions, or delivery needs. Preserve the package relationship so a combined submission remains traceable without hiding an unfinished component.
What happens when the assigned reviewer leaves?
Record the reassignment and its date while preserving the original submission and response target. Confirm that the replacement can retrieve the current revision and prior comments under the project’s permissions. An updated contact name alone does not establish that the new reviewer received the package.
What if the required-on-site date is not known?
Mark it unresolved and assign the schedule owner to provide a supported date and activity reference. You can still track review status, but the register cannot calculate a dependable release deadline without that input. Preserve any provisional date as an assumption rather than presenting it as an approved requirement.