How to Define Submittal Review Deadline Rules Before a Shop Drawing Sits Unanswered and Delays Procurement

Submittal review is one of the most time-sensitive handoffs in a construction project, and it is one of the least governed by explicit written rules inside the platforms teams use to manage it. A shop drawing enters a submittal log, an engineer of record or design consultant receives a notification, and from that point forward the timeline is often managed by habit, verbal agreements, and the hope that someone checks their queue before the procurement window closes.

When fabrication lead times are long, the gap between when a submittal arrives and when it must be approved is not flexible. Structural steel connections, custom mechanical equipment, curtain wall assemblies, and specialty electrical gear all carry fixed manufacturing schedules. If a reviewer holds a submittal for three weeks on a cycle that required a ten-day turnaround, the fabrication slot moves, the delivery shifts, and the schedule impact travels downstream faster than any change order can address it.

Why Platforms Alone Do Not Solve This

Most construction management platforms provide a submittal log with status fields and date columns. Some send automatic notifications when a submittal is assigned for review. What they do not provide, unless someone configures it deliberately, is a written rule set that defines what a review deadline means, how it is calculated, what happens when that deadline passes without action, and who is responsible for each step in the routing chain.

The result is a common failure pattern. A submittal arrives, a notification goes to a reviewer, the reviewer is managing twenty other deliverables, the notification ages in an inbox, and no secondary alert fires because no one ever configured one. The submittal log shows the item as "in review" indefinitely. The procurement schedule shows an expected approval date that has already passed. The two systems are not connected by any rule that would surface the conflict.

What Written Rules Should Cover

A functional submittal deadline rule set addresses at least five things before the first submittal enters the system.

First, it defines how review periods are counted. Some teams count calendar days. Others count business days and exclude holidays. When a contract specifies a ten-day review period and the platform counts calendar days over a holiday week, the reviewer and the contractor may operate under different assumptions about when the deadline falls. The written rule should specify which calendar convention applies and reference any contract language it is translating into platform configuration.

Second, it defines who the responsible reviewer is for each submittal category, not just the firm but the named role or individual assigned at project start. When a submittal arrives and routing is ambiguous, it often waits for someone to claim it. Assigning reviewer responsibility by discipline and submittal type before the project begins removes that ambiguity.

Third, it defines what happens at defined intervals before and after the deadline. A suggested approach is to configure a reminder notification at the halfway point of the review period, a second notification 48 hours before the deadline, and an escalation notification to a project manager the day a deadline passes without an action recorded in the log. Without these configured intervals, the platform treats a missed deadline the same as an open item: it waits.

Fourth, it defines what constitutes a completed review action. Some platforms allow a reviewer to leave a submittal in review status while adding internal notes. That does not constitute an approval, rejection, or request for resubmission from the contractor's perspective. The rule should specify which status codes in the platform represent a final disposition and require that final dispositions include a written response, not just a status change.

Fifth, it defines how the submittal log connects to the procurement schedule. If the platform managing submittals is separate from the scheduling tool, a written rule should specify how approved submittals trigger procurement milestones. In practice, this often means a manual update step, and the rule should name who performs that update and within what timeframe after approval.

Connecting Submittal Deadlines to Float Consumption

One of the more useful exercises a project controls team can perform before a project begins is to map submittal approval deadlines directly onto schedule float. For any activity with a long fabrication or delivery lead time, the latest date a submittal can be approved without consuming float is calculable. When that date is embedded in the submittal log as the governing deadline rather than an arbitrary review window, reviewers and project managers can see in concrete terms what a delayed approval costs in schedule days.

This connection also creates a more defensible record if a delay claim arises. A submittal log that shows a deadline tied to a schedule milestone, a notification sent to a reviewer, a missed deadline with no recorded action, and a subsequent procurement delay provides a cleaner factual record than a log that simply shows an approval date and a delivery date with no documented interval in between.

Configuring the System Before Work Begins

The practical window for establishing submittal deadline rules is during project setup, before any submittals enter the system. At that point, the team can agree on calendar conventions, assign reviewers by category, configure notification intervals, define disposition codes, and document the connection between submittal approvals and procurement milestones. Each of those decisions takes less time to make at setup than to untangle after a delay has already occurred.

If the project is already underway and submittal rules were never formalized, the same exercise is worth completing even mid-project. The team can audit the current submittal log for items sitting in review past their expected turnaround, identify which of those have procurement implications, and use that audit to build the rule set that governs the remainder of the project. It is not an ideal starting point, but it is better than allowing the existing pattern to continue through closeout.

A Note on Multi-Reviewer Routing

Some submittals require sequential review by multiple parties, for example a contractor review followed by an architect review followed by an owner review. When routing is sequential, the written rule set should specify whether the total review period is shared across all reviewers or whether each reviewer receives the full period independently. Shared periods compress quickly when the first reviewer uses most of the available time. Defining this before routing begins prevents the last reviewer in the chain from receiving a submittal with two days remaining on a window that was intended to be ten.

Submittal management is not a glamorous configuration problem, but it is a consequential one. The platforms exist. The notification tools exist. The schedule connections are possible to build. What is missing in most project setups is the written rule set that tells the platform how to enforce the timeline everyone assumes is already being managed.