Submittal register and schedule: calculate the submit-by date from field need

The Buildalytic workflow

Buildalytic offers submittal coordination workflows. Its workflow offering connects package requirements, responsible people, due dates and follow-up so the team can see what must happen before procurement. The steps, contacts, approvals and record destinations are agreed with your team during setup.

Do not begin with the date a subcontractor thinks it can submit. Work backward from the required delivery or field event using the actual review and procurement assumptions. The result is a planning calculation that the project team must confirm, not a guarantee that reviewers or suppliers will meet every date.

Sources: workflow offering; discuss the setup

Separate completeness from timing

A register can contain every identified item and still fail to protect the schedule. Conversely, a beautifully calculated timeline can omit an entire requirement. Review completeness and timing as distinct tasks.

Use the specifications, drawings and project requirements to identify candidate submittals. Have the responsible project staff check scope, applicability and ownership. Automated extraction can help assemble the list, but a phrase found in a specification is not automatically a complete, approved register entry.

Record the source section and version. If a design revision changes the requirement, the team needs to find the affected item. A generic title such as “mechanical submittals” makes that review harder than a source-linked description of the specific package.

Define the field event precisely

“Needed in June” is too vague for backward planning. Identify whether the milestone is approval, purchase release, delivery, inspection or installation. Those events can be weeks apart.

Ask the superintendent, trade and procurement owner to confirm the dependency. A piece of equipment may need to arrive before its installation date for receiving or preparation. A sample may need approval before the purchase order can be released. Use the actual sequence for the item.

Keep the schedule activity reference with the register entry. That connection makes a changed field date visible to the person responsible for the submittal. A date copied into a spreadsheet once can become stale when the project schedule moves.

Calculate backward with stated assumptions

Use a simple planning relationship:

Submit-by date = required field event − downstream procurement time − review allowance − revision allowance − other agreed buffers

Do not mix working days and calendar days. Label the calendar and explain which periods include weekends, holidays or shutdowns. The equation is easy; inconsistent date assumptions are often the harder problem.

Procore’s submittal documentation describes schedule information and required-on-site delivery fields. Use the current software documentation for its behavior. The manual calculation here is an editorial example that can also be used to check a configured workflow.

Sources: Procore’s submittal documentation

A fictional calendar example

Assume an item must be delivered on September 30. For a deliberately simplified calendar-day example, the project team allows 35 days for fabrication and transport after release, 14 days for design review, seven days for internal coordination and seven days for one revision loop.

The total allowance is 63 calendar days. Working backward from September 30 gives a planned submit-by date of July 29. Record the assumptions beside that date rather than displaying July 29 as though it were a contractual fact.

If the supplier later changes the lead time to 49 days, the required submission timing moves earlier by 14 days unless the team agrees on another recovery measure. Mark the affected assumption and ask the owner to confirm the response. Do not quietly leave the old date in the register.

Give every package an accountable owner

An item needs a preparation owner, a review route and someone responsible for the next handoff. Several people can participate, but the register should identify who is expected to move the record forward now.

A status such as “with subcontractor” is insufficient when the next required event is unknown. Record “trade preparing coordinated package, draft due July 22” or another specific action. The point is to expose what must happen next, not merely where the file currently sits.

Confirm dependencies between packages. A controls package may need information from another submittal. Record the dependency with its own owner and required date. Otherwise, a late response can appear as a mysterious delay in the final package.

Treat resubmittals as schedule events

When a package returns for revision, preserve the review comments and identify the action required. Update the revision assumption using the actual response, then recheck the field milestone.

Do not simply reset the original submission date and erase the previous cycle. The history explains what happened and helps the team distinguish late preparation from a long review or an incomplete response.

A revised package should also identify which comments it addresses. A comment-response crosswalk can make the next review more efficient. That is a proposed operating practice; it does not replace the reviewer’s authority or the project’s formal submittal procedure.

Keep approval and purchase release separate

An approved or reviewed submittal does not necessarily mean the order has been released. The purchasing owner may still need commercial approval, quantity confirmation or another project decision.

Record the actual release confirmation and supplier commitment separately. Link the submittal item to the procurement record, rather than forcing the submittal status to stand in for every later event.

This is where the register connects to Buildalytic’s existing approved-submittal-to-procurement guide. The current guide covers the earlier stage: identifying the package and protecting the time needed to reach that handoff.

Sources: approved-submittal-to-procurement guide

Review risk by consequence, not just age

An item overdue by two days can be critical if no float remains. Another item can be older without affecting the next field event. Show the required date, current forecast and dependency alongside age.

At the weekly review, ask what changed since the last meeting. Was a source requirement revised? Did the supplier change its lead time? Did a reviewer request more information? Each change should lead to a specific action and owner.

Avoid declaring a delay or entitlement from the spreadsheet alone. The register supports project decisions and preserves evidence. Contractual responsibility and formal schedule analysis require their own review.

How Buildalytic handles this workflow

Use Buildalytic’s custom workflows to connect the source requirement, package owner, reminder and next decision. Its supplier follow-up workflow explains the related supplier handoff.

A useful demo starts with one missed package and one changed lead time. Ask the system to show the governing source, recalculate the planning assumption and route the unresolved decision. Keep Procore or the chosen system of record in the process rather than creating a disconnected second register.

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; supplier follow-up workflow; discuss the setup