Best Practices: Submittal Project Configurations

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 When does the Submittals tool send email notifications to Procore users?

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.