Best Practices: Submittals

Introduction

Before your team starts creating submittals, you will want to make sure that you have all of your company level configurations in place. This will help prevent problems and re-work later on. Are you ready?

Custom Submittal Types

With Procore's Submittals tool, you can route any type of document that might require an approval workflow on your project. Submittal Types allow you to organise those documents by creating separate categories of submittals. See Create Custom Submittal Types. Your project team can filter and report on submittals based on their type to easily find the data they need.

Custom Submittal Statuses

Procore provides 3 default statuses for submittals: Open, Closed and Draft. However, you might want to add more statuses to show exactly where a submittal is in its submission and approval process.

An "Open" submittal can be:

• A submittal that has been requested, but not yet received
• A submittal that has been received and is being reviewed( either internally or externally)

A "Closed" submittal can be:

• A submittal that has been approved, with or without exceptions
• A submittal that has been rejected or marked as "Revise & Resubmit"

Configurable Fieldsets

Use Configurable Fieldsets to help make sure that your project team only sees and completes the fields that are applicable to your company's processes. See Create New Configurable Fieldsets.

Custom Fields

Custom Fields allow your teams to capture data unique to your company and/or project. See Create New Custom Fields.

Introduction

In order to get the most out of the Submittals tool, you will want to make sure that you have all of your project-level configurations in place before creating submittals. This article will go over the best practices for the most notable settings. Are you ready?

Number Submittals by Spec Section

This setting enables an option to prefix the submittal number and revision with the linked spec section. For example, if a spec section #03 30 00 is identified in the Specification Section field of a submittal, then the submittal number (such as #007) and revision number (such as #01) will be formatted as #03 30 00-007.01 when the setting is enabled. If the setting is not enabled, the submittal number and revision number will be formatted as #007.01.

Also, submittals in each spec section will be numbered sequentially and independently from submittals in another spec section when this setting is enabled. For example:

• Spec Section: 03 30 00
  • #03 30 00-001: Concrete Mix Design
  • #03 30 00-002: Product Data
  • #03 30 00-003: Expansion Joint Layout
• Spec Section: 07 45 00
  • #07 45 00-001: Product Data
  • #07 45 00-002: Samples

Dynamic Due Dates

Dynamic Due Dates are an optional but recommended configuration that defines workflow step durations instead of fixed due dates. This ensures each workflow step and role has its contractually obligated time frame to review and respond to each submittal item. As workflow steps are completed, the next step's due date automatically adjusts forward (if the previous step was late) or backward (if the previous step was early) to always comply with the defined durations. Overdue rules still apply if the workflow steps do not respond by their due date. See What are dynamic approver due dates?

Submittal Programme Calculations

Submittal programme calculations are an optional but highly recommended feature that displays relevant milestone dates for a submittal item. These fields consist of the following:

• Required On-Site Date: A user entry field for the date the submittal is to be installed or used on-site. 
• Lead Time: A user entry field for the number of calendar days the submittal requires for processing, manufacturing and shipping. 
• Design Team Review Time: A user entry field for the calendar days allocated for external teams to review and approve the submittal.
• Internal Review Time: A user entry field for the calendar days allocated for internal teams to review the submittal.
• Planned Return Date: A system-generated field to display the milestone date of when you require an approved submittal from your external reviewers to meet the Required On-site date milestone, also commonly known as the "drop dead date."
  • The calculation used to determine this is: Required On-site Date - Lead Time
• Planned Internal Review Completed Date: A system-generated field to display the milestone date of when you require a reviewed submittal from your internal reviewers to meet the Required On-site date milestone.
  • The calculation used to determine this is: Required On-site Date - Lead Time - Design Team Review Time
• Planned Submit By Date: A system-generated field to display the milestone date of when you require a submittal to be submitted from your Submitter role to meet the Required On-site date milestone.
  • The calculation used to determine this is: Required On-site Date - Lead Time - Design Team Review Time - Internal Review Time

These fields support the ability to back-calculate planned due dates for each member of  the workflow process based on specific required on-site dates, lead times and allotted review times. This setting makes it easier to report on the progress of a submittal to determine if it's on track.

When the 'Submittal Programme Calculations' option is turned ON:

• First enter a date in the Required On-Site Date field. 
• Next, enter the days in the Lead Time field. For example, if you enter 10 days, the system will automatically add the Planned Return Date by subtracting the 10-day lead time from the Required On-Site Date.
• The same is true for dates entered in the Design Team Review Time field. For example, if you enter 7 days, the system subtracts 7 days from the Planned Return Date to calculate the automatic entry for the Planned Internal Review Completed Date. 
• Finally, enter the days in the Internal Review Time field. For example, if you enter 5 days, the system will subtract 5 days from the Internal Review Time date to automatically calculate the Planned Submit By Date.

Enable Reject Workflows

This setting is highly recommended. When enabled, submittal responses of either 'Reject' or 'Revise and Resubmit' from a workflow approver automatically route the Action required by to the Submittal Manager to determine the next step.

• The Submittal Manager will be notified by email that they are now the Action required by user due to a 'Reject' or 'Revise and Resubmit' response. When the Action required by is routed to the Submittal Manager, they can choose to:
  • Close the submittal and create a revision if desired.
  • Return the Action required by to the previous step in the workflow.
  • Resume the workflow.
    • When a workflow is resumed, it will pick up where it left off. For example:
      • If the 'Reject' or 'Revise and Resubmit' response was entered on a step with no other approvers, the workflow moves to the next step. If there is no next step, the workflow completes.
      • If the 'Reject' or 'Revise and Resubmit' response was entered on a step with with more required approvers who haven't responded yet, the workflow will resume at the same step so the other required approvers can respond.

Submittal Emails

These settings regulate which Submittal roles will be copied on email notifications resulting from a specific submittal action. These notifications can be configured as needed to change the number of notifications being sent. See Who receives an email when a submittal is created or updated?

Defining Submitter, Approver and Reviewer Roles

These roles identify the specific actions required of the Assignee on a submittal item. The roles and their specific actions include:

• Submitter: As an optional but recommended first step in the workflow, the submitter role is responsible for submitting the requested documentation. Multiple users can be added to the "Submitter" role, but there can only be one Submitter step in a workflow. 
• Approver: These users are responsible for responding to the submittal item. The response options can be configured within the project's Submittals tool configurations. See Manage Custom Submittal Responses.
• Reviewer: This role is commonly used to provide the Approver role flexibility to send an item for review to another user not previously added to the same workflow step. An Approver can only do this when the item is in their action required by. Once the item is forwarded to them, the Reviewer can take similar response actions as an Approver. The action required by returns back to the Approver for their final response. See Forward a Submittal for Review.

See Submittals - Workflow Diagrams for a visual of how these roles work together in a submittal's lifecycle.

Submittal Responses

These settings allow you to customise the responses that can be used by Reviewers and Approvers. For example, you can add "Reviewed" as your project’s preferred response instead of "Approved". Submittal Admins can create up to 12 custom responses for each default response, except for "Pending" and "Submitted" which each allow one custom response. Custom responses cannot be deleted if they are being used on a submittal. They can be edited, but note that the edited response will replace the previous response in all of the places the previous response was used. See Manage Custom Submittal Responses.

Workflow Templates

Throughout the course of a project, teams constantly reuse the same workflow across multiple Submittals. Teams need to be able to define these workflows as templates and apply them when necessary, rather than having to recreate the same workflow for multiple submittals manually. If a Project Engineer is going to build the same workflow across 10 different items, that is a lot of extra time spent performing a repetitive action. With this feature, templates can be created and reused as needed. 

Next Steps

Now that your project's submittal configurations are in place, you can start creating submittals. The fastest methods to create a submittal registry are using Procore's Submittal Builder or Submittal Imports. See Best Practices: Submittal Builder and Best Practices: Submittal Imports for more information and recommendations for using these methods.

Introduction

Submittal Imports is the most efficient method to bulk generate a submittal registry with detailed data for your project’s submittals and packages. This guide will show you the best practices to help you maximise efficiency when using Submittal Imports. Are you ready?

Using the Import Template

First, download the submittals import template directly from the Procore Imports app or from our Support site here: Download the Submittals Import Template.

Next Steps

Now that your submittal registry has been created from the import, we recommend using Procore's Submittal Packages feature to initiate a workflow for multiple submittal items. See Best Practices: Submittal Packages - Creation and Review.

Alternatively, Procore's bulk actions feature can add a workflow to multiple submittal items from the list view. See Best Practices: Submittal Project Configurations.

Introduction

Procore's Submittal Builder is likely one of the fastest methods to create a Submittal Registry if your project has a published specification book. Submittal Builder can find submittals based on specific formatting in a spec book and create a basic submittal register. This guide will show you best practices to help you maximise efficiency when using Submittal Builder. Are you ready?

Why should I use Submittal Builder?

Generating a submittal register at the beginning of a project helps prevent critical submittals from being forgotten. What would take someone weeks to do manually can be completed with significantly less time and effort using Submittal Builder.

Ideal Specification Formatting for Submittal Builder

Submittal Builder looks for specific components when it processes a spec book. If these components are missing, few or no submittal items will be detected. Please review the information below and review your spec book to ensure these rules are being followed:

1. OCR technology is heavily reliant on the quality of the PDF document. For this reason, we highly recommend using Vector-based PDFs whenever possible. See What is the difference between raster and vector content in PDFs? for more information.
2. Submittal Builder only looks for submittal information within section headings that have the English word "submittals" in it.
3. Within the "submittals" subsections, items need to be indented to be captured properly as individual submittal items.
4. On each item's name, Submittal Builder looks for any exact matches to your company's submittal types (default or custom) before a colon (:). If no exact match is detected, the submittal type will be selected as "Other" by default.

Submittal Item Creation from Submittal Builder

Before confirming submittals in the Submittal Builder's review process, you should know how you want your project's submittals organised in Procore. To better understand submittal organisation in Procore, please see Best Practices: Submittal Packages - Introduction.

Submittal Builder creates submittal items with the following user-confirmed fields populated:

• Title
  • Note: Since the Title usually contains text related to the submittal type, verify the "Submittal Type" field is accurate before you configure and apply the Title. Applying the configured title will automatically update any existing titles on submittals waiting to be confirmed. Changing the 'Type' of a submittal manually after configuring the titles won't automatically update the submittal's 'Title'.
• Type
• Description
• Submittal Manager

Submittal Builder creates submittal items with the following fields pre-populated by the system:

• Spec Section Number & Description
• Status (All submittals created will be in Draft status.)
• Submittal Number
  • Note:
    • If the project has the "Number Submittals by Spec Section" setting enabled, then the submittals will be numbered accordingly within their spec section. For example: 
      • 06 25 09 - 001
      • 06 25 09 - 002
      • 06 25 09 - 003
    • If the project has the "Number Submittals by Spec Section" setting disabled, then the entire list of reviewed submittals will be numbered sequentially, regardless of the spec section number.

Next Steps

Now that your submittal registry has been created with the above mentioned fields, there are many more fields that should be updated for additional context. To add this remaining information on your submittals, we recommend using Procore's bulk actions feature to edit multiple submittal items within packages. See Bulk Edit Submittals in a Package. Procore's bulk actions feature can also be used to edit multiple submittal items outside of packages. See Use Bulk Actions > Edit in the Submittals Tool.

See Also

Best Practices: Submittal Packages - Creation and Review

Introduction

Understanding how you want to organise 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 site teams. Often, site teams are not considered enough at this stage, which can lead them to struggle finding approved documents later on. Also, changing your submittal organisation 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.

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 site 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 site staff.

• Because items are recommended to be listed individually, the likelihood that a critical submittal is overlooked is significantly reduced.
• Individual item organisation 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, site staff spend less time searching through separate packages and large PDFs containing multiple items.

Next in this Series

Best Practices: Submittal Packages - Submittal Itemization

See Also

• Best Practices: Submittal Packages - Creation and Review
• Best Practices: Submittal Packages - Distribution and Revision
• Best Practices: Company Level Submittal Settings

Introduction

Once you have determined how you will organise your submittal packages, the next step is deciding how to itemize the submittal items within each package (typically called the Submittal Registry). There is no right or wrong way to set up your submittal registry, but there are certainly pros and cons for each option.

A submittal registry traditionally begins with the specification, so let's start there. Here is a typical spec book sub-section for lighting fixture submittals:

We recommend that you start building your submittal registry by creating an individual line item for each of the items identified as requirements in the specification. In our example specification section above, these items are: Product Data, Shop Drawings, Qualification Data, Product Certificates, Field Quality Control Reports, O&Ms and Warranty.

Itemization Options

Next in this Series

Best Practices: Submittal Packages - Creation and Review

See Also

• Best Practices: Submittal Packages - Introduction
• Best Practices: Submittal Packages - Distribution and Revision
• Best Practices: Company Level Submittal Settings

Introduction

In this article, you'll find the recommended sequence of events to maximise the use of submittal packages.

Step 1: Create Submittal Packages and Items

Step 2: (Optional) Manage Submittal Item Numbering in a Package

We recommend that you use 0 as a temporary placeholder for your submittals' numbers when you create them because it can be difficult to know the order in which you'll receive and send them. As you receive the submittal items but before you send  them for review, click the "Edit" button on the package. In this edit mode, you can inline edit the submittal numbers. Once the submittal numbers are set, continue to the next step to bulk edit the package and send the items for review. 

Step 3: Bulk Edit Submittal Items in a Package

When a submittal registry is created early (before buyout, for example), the known details within submittal items are generally limited. Via the "Bulk Edit" button within a submittal package, you can quickly add the missing data to multiple submittal items within a package as the information becomes known. You can also apply a workflow from the same screen. Without using packages, this would be two separate steps for each group of submittals if you did the same thing via the list view bulk edit option.

Step 4: Initiate Workflows and Digest Email Notifications

Once workflows have been added to the items within the submittal package, you are now ready to send the "Action Required" emails to the first person in the workflow. Unlike creating submittals individually where multiple notification emails go out once you click "Create and Send Email", packages take a different approach that results in a single email sent to each user.

After a workflow has been added to at least one submittal in a package, a new alert banner will appear on the package view page. This banner allows for an Admin user to initiate a single "Action Required" email to the first person in the workflow. Fewer submittal emails is a major benefit for using the package functionality.

We recommended that you send emails for all the submittal items within a package at the same time. You can add new items to a package at any point, but clicking "Send Now" in the package alert banner will also resend any previously sent email(s), which could cause confusion for your Submitters/Approvers.

Step 5: Submitter Role - Package Review and Response

Once you click the "Send Now" button, the "Action Required" email shows the recipient all submittals that are now require their response (4 items in this example). They can click the "Review in Procore" link to go directly to the page in Procore where they can submit their requested response and documents.

In the example review page below, you can see all four items have the Door Contractor listed as the 'Action required by'. This view is where users can see and respond to all of their items from a single page and is another major benefit to using packages. Clicking "Review" for each item shows its Due Date and includes the fields for users to enter their response, comments and attachments.

Because the workflows exist on the individual submittal items, due dates do not need to be the same for each submittal in a package. In the example above, we included a submittal item for a Close out Warranty that is not due for several months. If the Door Contractor is not ready to submit this item right now, they can submit the other three items without getting delayed by this one close out item. The Door Contractor will stay listed as the 'Action required by' for the warranty until it is submitted. Overdue email notifications will also be sent to the Door Contractor if they do not submit by the due date. This is a great way to keep on track for close out deliverables. If your project's design teams prefer to receive "complete" packages, you can easily move any close out item to a separate package. 

Step 6: Approver Role - Package Review and Response

The Approver's process is similar to the Submitter's process described above. The Approver receives a single "Action Required" email with the three items in that package that they need to review. Following the "Review in Procore" link in the email, the review screen is nearly identical to the Submitter role. The only differences are the selections available under the "Response" dropdown and the "Previous Response" section.

Again, because the workflows exist on the individual submittal items, they can each be forwarded to another user or approved separately. Regardless of how the submittal items proceed, each user remains listed as the 'Action required by' until they post their response.

Next in this Series

Best Practices: Submittal Packages - Distribution and Revision

See Also

• Best Practices: Submittal Packages - Introduction
• Best Practices: Submittal Packages - Submittal Itemization

Introduction

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.

Package Distribution

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.

Package Revisioning

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:

Conclusion

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.

1. Submittal packages can be utilised as simply an organisational tool without sending workflow notifications from the packages. Think of it as just another way to view and group submittal items.
2. 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.
3. 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.

See Also

• Best Practices: Submittal Packages - Introduction
• Best Practices: Submittal Packages - Submittal Itemization
• Best Practices: Submittal Packages - Creation and Review

Introduction

The workflow section enables the Submittals tool's notification and action required by tracking components. Workflows provide the benefit of automated workflow progression and action/overdue notifications. This article will discuss best practices for editing Submittal workflows. Are you ready?

Bulk Actions > Apply Workflow

This feature allows Admin users to select multiple submittal items in bulk and apply a new workflow or pre-created workflow template. To apply a workflow in bulk, all submittal items must be in draft status AND have no previously applied workflow. The two options for bulk-adding workflows to submittals are described below.

Bulk Replace a User

People regularly move in and out of projects, so there needs to be a way to replace a workflow user with another user easily. If you need to replace an approver, submitter or reviewer on a large number submittals, a user with 'Admin' level permissions on the project's Submittals tool can do so in the Submittals Tool Configuration Settings. See Configure Settings: Submittals Tool.

Reject Workflow & Reverting Action required by to a Previous Step

In many scenarios, an Admin might need to revert action required by on a submittal back to a previous workflow step. Some example scenarios include:

• A workflow user forgets to upload an attachment or uploads the incorrect attachment to their response
• A workflow user provided the incorrect response
• The submittal was routed to incorrect approvers

At any point in time, a Submittal Manager can revert action required by to a previous step. For a more automated experience based on specific responses, we recommend enabling the 'Reject Workflow' setting. See Configure Settings: Enable Reject Workflows.

Submittal Revisioning

The 'Create Revision' functionality creates a copy of the original item's details (under a revision number), excluding any previously entered data within the workflow. The workflow steps will be copied but the order will restart from step one so you can request a new submission from the Submitter role. This functionality ensures all historical data is maintained within the original submittal item while allowing new data to be added to the revision.