Best Practices: Submittal Packages - Introduction
Note
This page describes recommended best practices for using submittal packages. Click here to view tutorials, videos, and more about the project's Submittals tool.Introduction
Understanding how you want to organize your submittals within your project before you start creating and sending them will lead to a lot less problems later on. Consider not only what works best for your design teams, but also be sure to take into account your field teams. Often, field teams are not considered enough at this stage, which can lead them to struggle finding approved documents later on. Also, changing your submittal organization plans is much more difficult after some submittals have already been sent for approval due to potentially mismatched submittal numbering between you and your design teams.
Problems Around Document Packaging and Approvals
A submittal is typically considered any document submitted by the contractor to the design team for the purpose of receiving approval for usage on a project (equipment, materials, etc). Historically, most construction professionals think of a submittal package as a single PDF that includes a cover sheet and all of their submittal items. When a package like this is sent to the design team, they may provide comments on the individual items, but generally provide a single response such as "Approved" or "Revise and Resubmit" for the entire package. When approvals relate to an entire package, it can create difficulties depending upon your company's submittal revisioning process.
Option 1: Only resubmit the rejected items under a package revision
In the image above, you can see the original submittal package was partially approved, with the rejected items getting approved on subsequent revisions. This is the most common revisioning method since it's typically the fastest. However, as shown in this example, there are three versions of approved documents related to the same submittal package. This forces field teams to waste time searching through multiple submittal revisions for a single piece of data. Also, because the items are not listed in a submittal register individually, it is easy for items to get lost or forgotten.
Option 2: Resubmit the entire package under a package revision
This is not as common as Option 1, but this is the best method from a document control perspective. However, this method can cause delays for already approved items and lead to design teams wasting time on nearly duplicate reviews. There is also potential for "Approved" items changing between revisions since reviewers tend to not pay as close attention to approved items on the later revisions.
Similar to the previous option, because items are not listed individually, items can easily get lost between package revisions, especially if previously approved items are changed later. Additionally, field staff need to read through much larger documents when they are likely looking for specific data.
Both of these submittal document revision options were developed well before digital files became commonplace and managing submittals was still a paper process. Neither option is the most efficient way to provide data access to the entire project team. As a result, Procore developed a new concept for Packages.
Submittal Packages in Procore
In Procore, individual items in a Submittal Package have their own workflows and approvals, instead of the package as a whole. Within Procore, individual items are more comparable to the familiar packages described above and submittal packages are more similar to a flexible grouping of related items.
The major difference with using submittal packages in Procore is how resubmittals are managed. In Procore, when resubmitting a package, only the rejected items are resubmitted but all items remain in the same package, eliminating the need to search through multiple document versions. Procore shows the most current versions of submittal items within packages.
If this feels a bit too unfamiliar, revisions can also be moved to a different package (acting as a package revision) if the design team prefers to keep them separate from previous submissions (example below). However, keep in mind that we don't recommend this option as it can be inefficient for field staff who would need to look through multiple packages to find item approvals.
Procore's unique submittal package concept addresses many of the document management difficulties experienced by project teams, especially field staff.
- Because items are recommended to be listed individually, the likelihood that a critical submittal is overlooked is significantly reduced.
- Individual item organization allows for specific submittals to be expedited at any point, yet remain connected under their associated package.
- Individual items can be revised as many times as needed but only the most current version is shown at any point in time. This reduces the risk that project teams will reference a previous version.
- When items are listed individually, field staff spend less time searching through separate packages and large PDFs containing multiple items.
How should Submittal Packages be organized in Procore?
Most contractors use one of three options to organize their packages: Trade/Responsible Contractor, Specification Division, or Specification Section. We recommend organizing your packages by Spec Section since packaging by Spec Division or Trade/Responsible Contractor can be too broad and lead to large packages that are harder to manage. Also, packaging by Spec Section is typically more accommodating and less challenging for multiple trades involved in similar scopes of work.
Example 1: Package by Spec Division
| #23 Mechanical Package | |||||
|---|---|---|---|---|---|
| Spec Section | Submittal # | Revision # | Title | Type | Status |
| 23 21 13 Hydronic Piping | 1 | 0 | Hydronic Piping Product Data | Product Data | Open |
| 23 21 13 Hydronic Piping | 2 | 0 | Hydronic Pumps Product Data | Product Data | Open |
| 23 23 00 Refrigerant Piping | 3 | 0 | Refrigerant Piping Product Data | Product Data | Open |
| 23 25 00 HVAC Water Treatment | 4 | 0 | HVAC Water Treatment Product Data | Product Data | Open |
| 23 31 13 Metal Ducts | 5 | 0 | Metal Ducts Product Data | Product Data | Open |
Example 2: Package by Spec Section, Combined by Submittal Type
| #23 HVAC Water Treatment Package | |||||
|---|---|---|---|---|---|
| Spec Section | Submittal # | Revision # | Title | Type | Status |
| 23 25 00 HVAC Water Treatment | 1 | 0 | Bypass Feeders Product Data | Product Data | Open |
| 23 25 00 HVAC Water Treatment | 2 | 0 | pH Controllers Product Data | Product Data | Open |
| 23 25 00 HVAC Water Treatment | 3 | 0 | Injection Pumps Product Data | Product Data | Open |
| 23 25 00 HVAC Water Treatment | 4 | 0 | Centrifugal Separators Product Data | Product Data | Open |
| 23 25 00 HVAC Water Treatment | 5 | 0 | Multimedia Filters Product Data | Product Data | Open |
If you choose to organize your packages by specification section (Example 2), there still might be instances where you have multiple responsible contractors involved with a single package. Fireproofing is a good example and, in these cases, there are two main options to ensure each company is receiving the appropriate information.
- Create a separate package for each responsible contractor using the same spec section. For example, create the packages "Fireproofing Package for Mechanical" and "Fireproofing Package for Electrical"
- Create a separate submittal item in the same package for each different responsible contractor and process the individual items separately. For example, create a "Fireproofing Package" with "Firestopping Product Data - Electrical" and "Firestopping Product Data - Mechanical" as the submittals within the package.