Tracing submittal approvals by spec section

How Procore links submittal revisions to a spec section and number, and where a reverted workflow can overwrite the approval record you need later.

A closed gray binder and a stack of manila folders on a site cabin desk, with a pencil, a tape measure and a small concrete sample beside them in soft morning light.

A project team can trace which submittal revision was approved against which spec section in Procore, as long as every revision is made with Create Revision and the approval history is never rewritten by moving Ball in Court back. We would switch on spec-section numbering and approval statuses before the first submittal goes out, and treat workflow reversals as a logged exception. This rests on Procore’s support pages What is a submittal revision?, Create a Submittal Revision, Best Practices: Submittals and Best Practices: Submittal Workflow Management.

Which revision governs for this spec section?

Take an illustrative case: a superintendent asks which shop drawings are approved for spec section 03 30 00. Document control finds three revisions, all marked Closed, and an approver response that was edited after a reset. The submittal exists. What is missing is a clear record of which revision governs, against which section, and who approved it.

Procore’s What is a submittal revision? page describes how this starts. When a team creates a new submittal and copies information from the previous one by hand, duplicate revisions can appear whose relationship to earlier revisions cannot be easily determined or linked. The page adds that there were no restrictions on the revision field, so numeric or alpha values, or even words, could lead to inconsistent and confusing results.

How Procore ties a revision to a spec section

What is a submittal revision? states the rule: for a revision to be linked to a submittal, it must share the same Spec Section and Number, and this happens automatically when you follow the documented steps. Create a Submittal Revision adds the constraints. You can only create a revision from the most current revision, general information is inherited, and the revision number increments by one. Attachments are not carried over between revisions.

Best Practices: Submittals describes the ‘Number Submittals by Spec Section’ setting. Enabled, spec section 03 30 00 with submittal 007 and revision 01 reads #03 30 00-007.01; not enabled, it reads #007.01. The same guide warns that without custom statuses such as ‘Approved / No Exceptions’ or ‘Rejected’, it could be difficult to find the final version if all revisions had ‘Closed’ as their status. The ‘Current Revision’ filter narrows the view to the latest item.

Our reading: the spec section lives in the number, and the approval lives in the status and response. Both need configuring before submittals are sent.

Where can approval history be overwritten?

Best Practices: Submittal Workflow Management covers reverting Ball in Court to a previous step. When you do that and new data is entered, previously recorded dates, comments, responses and attachments are overwritten. The changes stay in the item’s change history but are not immediately obvious, and reporting in Procore only displays the most current data. Best Practices: Submittals says the edit actions are not reportable in reporting tools, and recommends closing and distributing the submittal and creating a new revision if historical data matters.

Create Revision works the other way. Per the workflow guide, it copies the original item’s details under a revision number, excludes previously entered workflow data and restarts the workflow from step one, so historical data is maintained within the original item. One more exposure sits in configuration: Best Practices: Submittals notes that an edited custom response replaces the previous response everywhere it was used.

Who decides how revisions are made on the project?

The decision is which revision practice the project standardizes on, owned by the Submittal Manager and agreed with document control; Create a Submittal Revision notes that only a user with ‘Admin’ level permission can change a submittal’s status.

Who decides how revisions are made on the project?
Option We would choose it when What we would check first
Close, distribute, then Create Revision Approval history must hold up at closeout or in claims Spec-section numbering and approval statuses are set
Revert Ball in Court A wrong attachment or wrong approver is caught early Nobody needs the dates that get overwritten
Package by spec section One section has many items approved separately Each package references a single spec section
Copy into a new submittal Not as routine practice Duplicates and free-text revision values in the log

What to do this quarter

  • Pull the submittal log for one active project, apply the Current Revision filter, and list items whose only status is Closed.
  • Check whether Number Submittals by Spec Section is enabled, and settle it before Submittal Builder runs on the next spec section revision.
  • Name one owner for custom statuses and responses, since an edited response replaces the old one everywhere.
  • Measure Ball in Court reversals per month against revisions created, using the change history.
  • Spot-check that attachments were reattached on each new revision.

What this means for a bottleneck worth $1M or more

This is worth redesigning as one domain when submittal revision errors feed rework, late material and claims across many projects. We would fix the flow first: one owner and one record per approval, numbered by spec section. Rules handle the predictable checks, such as matching spec section and number. AI reads the messy part, such as reviewer comments on a package. People approve the consequential decisions, and AI never decides alone. See how we treat revisions and RFIs as one bottleneck within project-information operations; the same record discipline applies to quote and order revisions.

Limits of this evidence

These are vendor support pages. They describe configuration and recommended practice in Procore, not how project teams record approval across spec sections in practice. They do not show how often Ball in Court reversals overwrite approval data, or what that costs in rework or claims. They say nothing about other document control products, and they offer no benchmarks for revision counts or review times.

Questions buyers ask

Does a new Procore revision keep the original approval record?

Best Practices: Submittal Workflow Management says Create Revision excludes previously entered workflow data and maintains historical data within the original submittal item. The earlier approval stays on the earlier revision.

Can one submittal package cover several spec sections?

No. Best Practices: Submittals says Procore does not currently allow multiple spec sections to be selected on a package.

Are attachments copied to a new submittal revision?

No. Create a Submittal Revision says attachments are not carried over between revisions, so they need to be reattached if desired.

Sources

Sources give context. Dates show when each was last checked.

  1. What is a submittal revision? - Procoresupport.procore.com · retrieved
  2. Best Practices: Submittals - Procoresupport.procore.com · retrieved
  3. Create a Submittal Revision - Procoreen-gb.support.procore.com · retrieved
  4. Best Practices: Submittal Workflow Management - Procoresupport.procore.com · retrieved

Bring the bottleneck worth solving.

In 30 minutes we pin down the bottleneck, give you one practical recommendation and tell you whether it fits. We solve bottlenecks worth $1M or more.