NoteThis page describes recommended best practices for using submittal packages. Click here to view tutorials, videos, and more about the project's Submittals tool.
In this final submittal package article, we'll talk about closing a submittal, issuing it back to the creator, creating revisions, and other helpful information.
Once submittal workflows have completed, the Submittal Manager typically sends individual items back to the Responsible Contractor/Submitter. Since each submittal item has its own workflow and approvals, all submittal items are distributed through separate emails as described in Distribute a Submittal.
Like distribution, there are no package level revisions since submittal items are approved individually via separate workflows. Referring back to Best Practices: Submittal Packages - Introduction, this prevents needing to choose between the two options identified under the "Industry" package. Only the items that need to be resubmitted are processed, which speeds up the overall time for approvals. Revisions for items in a package can be managed in multiple ways, but here are the two most common:
Option 1: Resubmit items within the same package
When a revision is created on a submittal item, all of the previous data carries forward automatically, including the package. This assumes that you want all submittal revisions to be contained within the same package. This option is the most commonly recommended method since it keeps everything bundled together for faster referencing, especially when combined with the "Current Revision" filter.
'Current Revision' Filter
Once applied on the Packages view, this filter will remain in place for your user account on a project until you remove it. This filter is especially helpful for field teams because it only displays the most current version of any submittal, regardless of the submittal's status (similar to "current set" in drawings). Below are screenshots of the filter:
NoteThis filter is one of the main reasons we recommend creating the revision immediately after the original rejected item is distributed. By doing so, you create a new line item right away that clearly indicates the item is still awaiting submission. This makes it much less likely that a field member will click on and build from an unapproved item.
Option 2: Resubmit rejected items in a new package
Using this option, you add a revised submittal into a newly created package. This can be helpful when your project's design team requires very stringent package controls and numbering. However, the downside is that you will have multiple packages to search through when trying to find a specific item.
In order to prevent items from getting forgotten, we recommend creating revisions immediately after the original rejected item is distributed, especially if you are using the "Submitter" role (see Create a Submittal Revision). The due dates assigned during this process and overdue notifications will help ensure nothing gets missed.
We hope these articles have clarified the purpose and benefits of Procore's submittal package functionality. While we realize this functionality may not be the best fit for every project or team, please consider these closing thoughts as you think about how to organize submittals on your next project.
- Submittal packages can be utilized as simply an organizational tool without sending workflow notifications from the packages. Think of it as just another way to view and group submittal items.
- If you are still unsure how you can use submittal packages, we encourage you to give them a try using broad itemizations. This option may look closer to how you've processed items before. If you decide it's not for you, you won't have a ton of submittal items to manage.
- While using submittal packages may not be the right choice for your project currently, the functionality will continue to evolve over time and may work for you better later or on another project. To stay informed about new releases, we encourage you to register for our New Release Webinar.