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:
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.
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 site 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:
Filter Off:
Filter On:
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 realise this functionality may not be the best fit for every project or team, please consider these closing thoughts as you think about how to organise submittals on your next project.