Skip to main content
Procore

Best Practices: Submittal Project Configurations

 Note
This page describes recommended best practices for setting up submittal configurations. Click here to view tutorials, videos, and more about the project's Submittals tool.

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?

Why should I do this now?

Enabling certain configurations provides additional functionality to help ensure your submittals are processed as efficiently as possible.

 Tip
If you want to set these configurations as default for all new projects, most of these settings will carry over in a project template. See What is a Project Template? and What gets copied over to a new project when applying a project template?

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

Considerations

After this setting is enabled and submittals are created, we do not recommend disabling the setting. Doing so will likely cause duplicate submittal numbers.

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?

Considerations

  • We recommend enabling the 'Dynamic Approver Due Dates' configuration before creating and using submittal workflow templates. 
  • Submittals workflow due dates comply with the project's Working Days settings. See Set Project Working Days.
  • Overdue submittal email reminders will not be sent once the submittal is 45 days past due. 

Submittal Program Calculations

Submittal program 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 Program 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.

Considerations

  • These fields are purely for reference only. They do not impact or sync with other fields, including workflow due dates. 
  • To avoid confusion and eliminate duplicate data, consider hiding the standard ‘Submit By’ date field in the Submittal tool fieldset. See Which fields in the Submittals tool can be configured as required, optional or hidden?
  • These calculations assume a perfect scenario with no submittal revisions. Be sure to consider the number of potential revisions when determining the actual workflow due dates.

Why should I enable Submittal Program Calculations?

Displaying this information allows you to add and reference these important dates when building your workflow to ensure that your submittal is approved by the required on-site date. See Enable Submittal Program Calculations and Set Up Submittal Program Calculations.

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 Ball in Court to the Submittal Manager to determine the next step.

  • The Submittal Manager will be notified by email that they are now the Ball in Court user due to a 'Reject' or 'Revise and Resubmit' response. When the Ball in Court is routed to the Submittal Manager, they can choose to:
    • Close the submittal, and create a revision if desired.
    • Return the Ball in Court 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.

Considerations 

  • This feature also applies to any custom responses mapped to 'Reject' or 'Revise and Resubmit' response types.
  • When the Submittal Manager chooses to set the Ball in Court back to a previous workflow step, none of the step's information (Attachments, Response, Comments Sent/Returned Dates) is removed. These items can be edited, but the original information is not stored within the submittal. The edit actions will be recorded in the change history, but are not reportable in reporting tools.  If maintaining the historical data is important to you, we recommend closing and distributing the submittal and creating a new revision instead of returning Ball in Court to a previous step.

Why should I enable Reject Workflow?

This setting simplifies workflows and eliminates unnecessary revisions. For interactions between the Submitter and Approver, it provides an opportunity for the Submittal Manager to address an incorrect submission from the Submitter before it can advance to the next Approver.

For workflows with multiple Approver steps, it eliminates the need to insert an extra step dedicated to the Submittal Manager between Approver steps to ensure that a 'Reject' or 'Revise and Resubmit' response does not advance to the next step. 
 

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?

 Important
These settings do not control any "Action Required" emails sent to Ball-in-Court 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 ball-in-court. Once the item is forwarded to them, the Reviewer can take similar response actions as an Approver. The ball-in-court returns back to the Approver for their final response. See Forward a Submittal for Review.
 Note
To effectively build submittal workflows, ensure the submitters, approvers, and reviewers have all been added to the project's directory. See Add a User Account to the Project Directory.

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. 

Considerations

  • Since submittal workflow steps are assigned to specific users and no step can be “unassigned”, it is likely that you will create new templates as you buy out scopes of work. 
  • If you prefer to avoid creating multiple workflow templates for each unique routing, you can create partial workflow templates containing only core workflow roles. Once workflow templates are applied, the remaining steps can be added and any existing ones can be modified. We typically suggest building workflow templates with no Submitter role, so you don't need to create a template for each Responsible Contractor. This works especially well if all submittal workflows are otherwise the same.
  • Once a submittal’s workflow is complete, the ball-in-court automatically returns back to the Submittal Manager. However, no due date is associated with this ball-in-court and no overdue notifications are sent. If you prefer to ensure the Submittal Manager distributes the submittal according to a due date, add that user as a final step to the workflow.

Why should I create workflow templates?

Creating workflow templates saves you time and ensures the required teams are reviewing the submittal items in the proper order. See Manage Submittal Workflow Templates.

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.