A construction submittal is project information submitted for review before specific materials, products, equipment, fabrication, or installation move forward. Depending on the work, a submittal may include shop drawings, product data, samples, calculations, certifications, or other supporting information.
A well-run submittal process connects the contract documents to procurement and field execution — showing what was submitted, who reviewed it, what action was returned, what revisions remain, and whether the item is ready for the next project step.
Submittal requirements, terminology, review authority, and status language vary by contract and organization.
Contract drawings and specifications define the design and the project requirements. They generally do not contain every piece of fabrication, manufacturer, product-selection, installation, or coordination information needed to procure and build every component.
Submittals create the project-specific review record between contract requirements, the selected product or fabrication information, the review, any required revision, and the downstream procurement, fabrication, or installation step.
The key idea. A submittal is not simply a file sent to the architect. It is a controlled project decision point between contract requirements and the work waiting behind it.
Submittals help teams verify that the specific product, material, equipment item, fabrication detail, or other proposed information can move through the review process the project requires before the affected work depends on it.
A useful submittal record helps the team answer:
The point is not document routing for its own sake. It is getting the right information reviewed before the affected work depends on it.
Not every project requires every type. The actual submittal schedule is governed by the project's contract documents and procedures.
Project-specific drawings showing fabrication, dimensions, layout, coordination, assembly, or installation information.
Manufacturer information describing products, equipment, systems, performance characteristics, options, and installation requirements.
Physical or documented examples used to review materials, colors, finishes, textures, or workmanship expectations.
Representative assemblies or installations used for review where required by the project.
Engineering or technical calculations submitted where project requirements call for them.
Documentation showing specified qualifications, test results, product characteristics, or other required certifications.
Reports, testing documentation, or technical records required before or during project execution.
Information related to selected materials, equipment, manufacturers, models, and relevant supporting data.
Warranties, O&M information, record documentation, certificates, or other closeout records where required.
These are all submittals, but they answer different review questions.
| Submittal type | Best understood as | Common examples |
|---|---|---|
| Shop drawings | Project-specific fabrication, installation, and coordination information. | Structural steel fabrication drawings, storefront shop drawings, millwork drawings, mechanical equipment layouts, reinforcing details, curtain wall details. |
| Product data | Manufacturer information about a proposed product or system. | Equipment cut sheets, roofing product information, fixture data, finish system data, hardware information. |
| Samples | Physical or representative review of appearance, material, or finish. | Paint color, flooring material, stone, tile, façade material, finish sample. |
There is no single universal workflow. Roles vary by contract and delivery method, but most projects distribute the work along these lines.
At every stage, the team should be able to answer four questions: who has it, what action is required, when the answer is needed, and what work is waiting on it.
Exact routing and review responsibility are set by the project, but the sequence below reflects how a controlled submittal moves from requirement to released work.
The team identifies the required submittal from the contract documents, procurement plan, or project procedures.
Work backward from required-on-site, fabrication, procurement, and installation dates to determine when review must be complete.
The responsible subcontractor, supplier, manufacturer, or project participant prepares the required information.
The GC / CM reviews the package according to project procedures before routing it onward.
The package is sent to the required architect, engineer, consultant, owner, or other reviewer.
The reviewer returns the package with the applicable review status and comments.
If revisions are required, the responsible party updates the package and routes it through the next review cycle.
Once the applicable project requirements are satisfied, the team moves the item into the appropriate downstream step.
Returned submittals, revisions, current status, dates, and final information remain available to the project team.
Exact routing, review responsibilities, status terminology, and contractual effect are governed by project-specific contract documents and procedures.
A common mistake is treating the planned submission date as the starting point. For time-sensitive materials and equipment, the useful approach is to work backward from when the item is actually needed in the field.
The useful question is not "When is the submittal due?" It is "When must this submittal be fully reviewed so procurement still supports the project schedule?"
Content varies by submittal type. This is not a universal legal checklist — a useful submittal record generally needs enough information to connect the package to its requirement, its review, the downstream work, and its current status.
The fictional example below shows how the fields work together on a common shop-drawing package. Example dates and project information only.
Status language is not universal. Numbering, routing, review periods, and the effect of a review action are governed by the project's contract documents and procedures.
Projects use different status terminology. The examples below are common, but status language and its contractual effect vary by project — the contract documents and project procedures control.
No further review cycle is required under the project's process before the applicable downstream step.
The item may move forward subject to incorporating the review comments according to project procedures.
The package requires revision and another formal review cycle.
The submitted item does not satisfy the applicable review requirements and cannot proceed as submitted.
Some organizations use alternate status language instead of "approved."
Some items may be submitted primarily for documentation rather than a traditional approval cycle.
This distinction is one of the most useful things a submittal register can get right. Review status records what came back from the reviewer. Workflow status records where the item currently sits operationally.
What action came back from the reviewer.
Where the item currently sits operationally.
A submittal can carry a review action and still require downstream work before the register should be treated as complete.
When a package requires another review cycle, preserve the history. Do not overwrite the original record — the team should be able to see what changed between cycles.
Both are formal project records, but they exist for different reasons and produce different outcomes.
| Record | Purpose | Common trigger | Result |
|---|---|---|---|
| RFI | Ask for clarification when project information is missing, conflicting, or unclear. | A question in drawings, specifications, coordination, scope, or field conditions. | A documented response or clarification. |
| Submittal | Route project-specific product, material, fabrication, equipment, sample, or related information through the required review process. | A contract requirement, procurement need, fabrication need, finish selection, or installation requirement. | A documented review action and next project step. |
An RFI asks a question. A submittal presents information for review. They are often related — a submittal review can raise a question, and an RFI response can change what gets submitted — but they are not interchangeable. For the full picture, see what an RFI is in construction.
"Submittal" is the broader category. A shop drawing is one type of submittal.
The umbrella term for project information sent through the required review process.
A project-specific drawing showing fabrication, layout, coordination, dimensions, assembly, or installation information.
Other submittal types include product data, samples, mockups, calculations, certifications, and equipment data.
A submittal review may reveal a coordination problem, a proposed deviation, a material substitution, a scope issue, or a design question that requires separate resolution. That does not make the submittal itself a change order.
If the review reveals a potential change to scope, cost, time, or contractual requirements, the project generally needs to route that issue through its separate change-management process. For how that works end to end, see the construction change-order process. To document a resulting contract change, use the free construction change order template.
For many products and equipment packages, procurement cannot move cleanly until the project has enough reviewed information to release the item. Not every product requires review before purchase, but the ones that do tend to carry the most exposure.
A submittal register becomes much more useful when it shows not only the review status, but what procurement decision is waiting behind it.
Not all submittals deserve equal priority. A routine finish item needed months from now is usually less operationally urgent than an electrical-equipment package needed to preserve manufacturing capacity or an upcoming release.
The chain is predictable: a late submittal pushes review, review pushes any resubmittal, the resubmittal pushes release, release pushes fabrication and delivery, and the installation or milestone behind it absorbs the pressure. That does not mean every late submittal delays a project — it means the connection needs to be visible.
A submittal can be open without being critical. The schedule connection is what tells the team whether an item deserves immediate attention, which is why teams increasingly review open packages alongside activities and milestones in construction scheduling software rather than as a standalone list.
A submittal document shows one package. A submittal log — often called a submittal register — shows every required package across the project, and whether each one is actually moving. If you need a register to start from, use our free construction submittal log template.
Fictional example data
| Submittal | Subject | Spec | Workflow status | Review status | Required on site | Priority |
|---|---|---|---|---|---|---|
| SUB-030 | Electrical switchgear product data | 26 24 13 | Design Review | — | Jun 15 | Critical |
| SUB-031 | Roofing system product data | 07 54 19 | Returned | Revise and Resubmit | May 30 | High |
| SUB-032 | Aluminum-framed storefront shop drawings | 08 41 13 | Returned | Approved as Noted | May 20 | High |
| SUB-033 | Level 3 carpet sample | 09 68 13 | Owner Review | — | Jul 10 | Normal |
| SUB-034 | Door hardware product data | 08 71 00 | Closed | Approved | Jun 01 | Normal |
Electrical switchgear product data
Roofing system product data
Aluminum-framed storefront shop drawings
Level 3 carpet sample
Door hardware product data
Fictional example entries only. These are not benchmark review durations. Field names and status values should follow the project's own procedures.
Submittal number, age alone, and specification order are poor prioritization signals. A more useful priority reflects what the item is holding up:
The oldest submittal is not always the one that matters most. A newly submitted long-lead equipment package can be more urgent than an older finish submittal for work months away.
Useful submittal reporting is less about benchmarks and more about exposure. The measures below tend to change how a project actually behaves:
Total submittal count alone says little about project risk.
The team knows when the package is due but not when the material or equipment is actually needed.
A returned submittal sits in the system even though purchasing or fabrication is waiting on it.
Missing product data, drawings, calculations, samples, or required supporting information creates another review cycle.
The package is routed without the required contractor / CM review or coordination step.
Nobody can tell who has the next action.
"Approved as Noted" is recorded, but nobody tracks whether comments were incorporated or the item was actually released.
The latest revision replaces the prior record instead of preserving the review trail.
A package is treated like any other document even though procurement or installation is approaching.
Returned or revised information exists, but the affected trade or superintendent does not have the current record.
A design or scope question is hidden in the package rather than routed through the appropriate separate process.
The review is one decision. After it comes back, the project may still need to complete several steps before the item is genuinely closed:
The project-control workflow continues until the information reaches the people and the work that depend on it.
On a smaller project, folders, email, a spreadsheet, and disciplined meetings may be enough. As volume grows — more specification sections, more subcontractors, more reviewers, more long-lead packages — teams start needing more structure:
None of this requires a specific vendor. It requires that review, procurement, schedule, and current project information do not live in disconnected places.
Jet.Build keeps submittals connected to the broader project record — including documents, RFIs, approvals, schedules, changes, responsibilities, and reporting — so teams can see both the review status and the work affected by it.
Submittals, statuses, dates, reviewers, and current responsibility stay visible in one project workflow.
Shop drawings, product data, samples, supporting files, and related project records remain associated with the submittal.
Teams can see who owns the next action and what is waiting.
Packages move through project-specific review paths with preserved history.
Submittals can remain connected to the project activities and dates that depend on them.
Questions and downstream change issues remain connected to the project record rather than disappearing into separate email chains.
Teams can review active submittal status across projects without rebuilding the picture manually.
Teams can also use Jenny, Jet.Build's built-in assistant, to surface underlying project records and summarize project information. Review decisions and project responsibility stay with the project team. Submittal timing also shows up directly in construction scheduling, where required-on-site dates meet the activities behind them.
At any point in the project, the team should be able to answer a specific set of questions without reconstructing them from email:
The submittal itself is a document package. Submittal control is the operating process that keeps thousands of those packages from becoming disconnected from procurement, schedule, and field execution.
Where submittals connect to RFIs, documents, schedules, changes, and project execution.
Take about 30 minutes with our team to see how Jet.Build connects submittals, documents, RFIs, approvals, schedules, changes, and reporting across active projects.
Schedule a Demo