Construction submittal review checklist: build a package the reviewer can use

The Buildalytic workflow

Buildalytic offers submittal intake and review-coordination workflows. Its workflow offering uses Brody to gather package information, request missing material and follow up with the assigned reviewer while preserving the source context. The steps, contacts, approvals and record destinations are agreed with your team during setup.

Use this checklist for preparation and internal completeness review. It does not replace design review or determine that a product complies. The people authorized by the project's process still make the relevant technical and contractual decisions.

Sources: workflow offering; custom workflows

Identify the package before collecting PDFs

Start with the submittal register entry, specification section, drawing reference and responsible trade. Define the package scope so the team knows whether it is reviewing one item, an assembly or a coordinated system.

Record the source revision. A package assembled against an old requirement can look complete while answering the wrong question. If the source changes during preparation, identify the affected material and ask the owner to review it.

Use a clear title and identifier. “Product data” is difficult to distinguish in a busy queue. A source-linked title describing the actual item and location helps the reviewer find the right record later.

Make the selection unambiguous

Manufacturer literature may contain several models, sizes, finishes and options. Identify which configuration is proposed. Do not make the reviewer infer it from an unmarked brochure or a handwritten note detached from the relevant page.

Keep the product identifier consistent across the cover information, data sheet, drawing and supporting records. If two identifiers differ, explain whether one is a supplier reference or a changed selection.

A useful internal check asks whether a reviewer unfamiliar with the package can identify the proposed item quickly. If they need to call the preparer to interpret the selection, improve the packet before routing it onward.

Create a source-to-product crosswalk

The crosswalk should point to evidence, not repeat marketing claims. “Meets all requirements” is less useful than the exact source and product passage the reviewer can inspect.

State deviations instead of hiding them

A deviation or proposed substitution needs the appropriate process and review. Identify the difference clearly and preserve the source reference. Do not rely on a reviewer discovering it among dozens of unmarked pages.

Keep the status factual: proposed, under review, returned for information or resolved through the formal record. A preparer's confidence does not create approval.

If your team is unsure whether a difference matters, record the question and route it. That is more useful than silently selecting the closest-looking product and hoping the review catches the issue.

A fictional hardware package

Suppose a trade prepares a door-hardware product-data package. The specification and schedule identify the relevant requirement. The supplier provides a catalog containing several finishes and configurations.

The preparer marks the proposed configuration, records the exact product identifier and links the relevant pages. One listed option differs from the source requirement, so the packet identifies it as a proposed deviation and routes it through the required review. It does not describe the option as accepted.

The internal reviewer checks the package scope, selected pages, source revision and open question. The formal reviewer then receives a coherent packet. The fictional scenario demonstrates preparation quality; it does not establish that a particular hardware selection is technically suitable.

Check attachments as records

Confirm that each file opens, pages are legible and the package contains the intended version. Identify missing sheets and duplicate or obsolete attachments. Do not let a filename ending in “final” stand in for a version check.

Use a consistent page reference in comments. A PDF page number and a printed sheet number may differ. Make the reference clear enough that the next reviewer can find the exact passage.

Procore's submittal PDF review documentation describes markup and attachment-version behavior. Use that documentation for current software behavior. A markup tool helps communicate the review; it does not independently establish compliance.

Sources: Procore's submittal PDF review documentation

Resolve dependencies before pretending the package is complete

Some packages rely on reviewed information from another trade or item. Record the dependency, owner and required information. If the package proceeds conditionally under the project's process, make the condition visible.

A controls package, for example, may depend on equipment information. Do not invent the missing parameters merely to produce a complete-looking drawing. The packet should tell the reviewer which inputs are confirmed and which remain unresolved.

Connect the dependency to the submittal schedule. A missing input can affect preparation and review timing. Use the companion register and scheduling method to expose that effect rather than discovering it at the planned release date.

Review the review route

Confirm the submittal manager, required internal checks and designated reviewers. A package sent to a convenient contact may not have entered the formal process. Record the actual submission event and reference.

Keep preparation approval distinct from technical review. A project engineer can check that the packet is assembled and complete without claiming to approve the proposed design or product.

If a reviewer requests a correction, preserve the comments and explain how the next version responds. A comment-response table with source references is often clearer than a new PDF that leaves the reviewer to rediscover what changed.

Handle resubmittals deliberately

Give each revision a clear identifier and retain the prior record. State which comments were addressed, which remain open and which source or product changed. Do not reset the history by uploading an unrelated replacement.

Check whether a changed product affects other package elements. A revised selection may require updated drawings or supporting records. The preparer should identify those relationships before declaring the comments complete.

When the formal review returns, record the exact disposition and any conditions. Avoid converting nuanced reviewer language into a single green “approved” badge that erases required follow-up.

Keep approval separate from procurement

A reviewed package does not necessarily mean purchasing has released the order. Link the final reviewed record to the procurement owner and preserve the release decision separately.

The existing approval-to-procurement guide covers that later handoff. This guide prepares the evidence that reaches the reviewer before the purchasing decision.

A useful operating chain is requirement → selected proposal → review → response to comments → formal disposition → authorized release. Staff should be able to find the source at each step without rebuilding the packet from email.

Sources: approval-to-procurement guide

Test the workflow with Buildalytic

Use Buildalytic's company knowledge and custom workflows around the package, owner and review task. Bring a fictional unmarked catalog, source requirement and unresolved dependency.

Ask the system to help organize the relevant material, preserve the source and route the missing question. The useful demonstration is a reviewable packet with visible uncertainty, not an AI statement that everything complies.

To put this Buildalytic workflow to work, discuss the setup with your project’s source records, responsible people and expected outcome. Use the checks in this guide to verify the agreed process before rollout.

Sources: workflow offering; custom workflows