RFIs and Submittals: How to Control Changes, Approvals, and Evidence on Site

Buildpeer

September 23, 2026

RFIs and submittals are part of the information exchange needed to execute a project correctly. Understanding what an RFI is in construction, and how it's different from a submittal, is the first step before you can control either one.

An RFI (Request for Information) is used to request a clarification when there's a question about drawings, specifications, or other project information.

A submittal, on the other hand, presents information about a material, piece of equipment, product, or proposed element so it can be reviewed against the project's requirements. It can include spec sheets, shop drawings, samples, manufacturer information, or other documents.

Even though both go through a review and response process, they serve different functions.

The challenge isn't just generating the document. It's also knowing what's pending, who's supposed to respond, how long it's been open, and what information came out of the review. That, at its core, is what submittal tracking and RFI tracking are about.

Why an RFI or Submittal Without Follow-Up Can Affect the Project

Sending an RFI doesn't mean the question is resolved.

While waiting for a response, the related activity might stall, or the team might end up without the information they need to continue according to what the project requires.

Something similar happens with submittals.

A material or element may need a review before certain activities can continue. If no one has clarity on the status of the submittal, the team can waste time asking whether it's already been reviewed, or working off information that doesn't match the current revision.

A common example: a contractor installs a finish while waiting on the answer to an RFI about the exact color, because stopping would mean losing the day. If the answer comes back different from what was assumed, that work gets redone. Neither path, stopping or moving ahead on an assumption, is free. The only difference is who pays for it and when it gets discovered.

Something similar happens with a submittal, just at a different point in the process. A supplier hands over the spec sheet for a piece of equipment, and while no one checks whether it meets spec, the purchase order can stall, or worse, it can go through before approval, risking that the equipment arrives and doesn't meet spec.

That's why, on top of logging RFIs and submittals, it matters to be able to identify which ones are still open, since when, and who owes a response.

What Information Should Get Logged

Each project can define its own review and approval workflow. Still, having a clear history makes it easier to understand what happened later on.

For an RFI, it helps to be able to check:

The question or clarification requested.
The date it was raised.
The person or team responsible for answering.
The response received.
The date of the response.
Related documents or references.

For a submittal, it's worth logging:

The material, product, equipment, or element submitted.
The relevant revision.
The date it was sent.
The person or team in charge of reviewing it.
The outcome of the review.
Comments or observations.
Related documentation.

The exact information will depend on the procedures set for each project.

What matters is that when someone needs to review what happened, there's a record, instead of having to reconstruct the conversation from emails, messages, or memory. This is especially true for submittal tracking, where there are often several rounds of review before a final approval, and losing track of which was the last reviewed revision can cost as much as never having done the review at all.

RFI vs. Submittal: What's the Difference

‍

The core difference is simple: an RFI resolves a question; a submittal presents information for review against the project's requirements.

Where Ambiguity Tends to Show Up in Practice

One of the most common problems shows up when a question gets resolved through a message, a phone call, or an isolated email that's later hard to tie back to the original RFI.

The answer might exist, but it's not necessarily available to everyone who needs to check it.

On top of that, an RFI can reveal that an additional clarification is needed, or even lead to a mid-project change, depending on the response and the procedures set for the project.

That's why it matters to distinguish between clarifying information and authorizing a change. An RFI on its own doesn't necessarily modify the scope, drawings, or specifications.

When a response does lead to a change, that decision should follow the corresponding process and get documented.

Something similar happens with submittals when there are several revisions of the same element.

If the team can't easily tell which revision is current and what the outcome of each prior revision was, the risk of working off outdated information goes up.

‍

What Changes When Tracking Gets Logged

When every RFI and submittal has an owner, a date, a status, and a history of responses, the team can check what's still pending without constantly asking around.

This also gives whoever is responsible for answering the context they need on the request, along with access to related information.

The benefit isn't just in storing documents. It's also in being able to answer operational questions like:

Which RFIs are still open?
How long have they been pending?
Who owes a response?
Which submittals are still under review?
Which revision is current?
What was the previous response?
What documents are tied to that decision?

When this information is organized, tracking depends less on people's memory and it's easier to check the project's history.

‍

RFIs, Submittals, and Version Control

Tracking RFIs and submittals is also tied to document control.

A response can clarify how certain project information should be interpreted. In other cases, it can kick off a process that later results in a new revision of a document.

That's why it's a mistake to assume that an RFI response automatically replaces a drawing or a specification.

If a new revision does get generated as a result, the team needs to identify the current document and make sure the field doesn't keep working off an earlier version.

Something similar happens with submittals. When there are several revisions, it needs to be clear which one applies, based on the review process defined for the project.

Keeping documents, responses, and revisions linked to each other makes it easier to check the history when needed.

On projects with several subcontractors, this gets trickier. Each one may have their own sense of how often to check the status of their RFIs or submittals, and without a shared place to check them, the responsibility for following up ends up falling on whoever is most proactive, not necessarily whoever should own it.

‍

Before the Next RFI Gets Lost in the Group Chat

Controlling RFIs and submittals doesn't mean generating more paperwork.

It means being able to know what's pending, who's supposed to handle it, how long it's been open, and what information got logged after each response or review.

When that tracking depends on isolated emails, chats, or someone remembering what happened, finding the right information can turn into an extra problem for the team.

Keeping an organized record lets RFIs and submittals do their job on the project: resolving questions, reviewing information, and leaving a history that can be checked when needed.

If you're looking for a better way to track RFIs and submittals on your projects, schedule a demo and we'll go over your case.

Preguntas Frecuentes

What is an RFI in construction?

An RFI (Request for Information) is a formal request for information or clarification tied to the project's documents or site conditions. It's used when there's a question that needs to be resolved so the team has enough information to move forward with a given activity. The workflow for issuing and answering an RFI depends on how responsibilities are set up on each project.

What is a submittal, and how is it different from an RFI?

A submittal presents information about a material, product, piece of equipment, or other element so it can be reviewed against the project's requirements. It can include spec sheets, shop drawings, samples, or other documents. The main difference is that an RFI asks a question or requests a clarification, while a submittal presents information for review. The two get confused often because both generate a document with a response date, but only the submittal requires evidence of compliance.

What happens if an RFI doesn't get answered on time?

It depends on the related activity. In some cases, the team may need to pause an activity until they have the information they need. In others, the missing response can affect the sequence or the schedule. That's why it matters to keep track of which RFIs are still open and whether any of them are tied to upcoming or in-progress activities. Catching this early keeps a delay from only surfacing once it's already affected another dependent activity.

Who should be tracking RFIs and submittals?

It depends on how the project and responsibilities are structured. What matters is having clarity on who raises the request, who's supposed to review or answer it, and who's responsible for following up on open items. Without that clarity, tracking tends to depend on whoever remembers to ask, instead of a defined process.

How do you avoid working off a submittal revision that's no longer current?

By keeping a clear history of revisions and the outcome of each one. The team should be able to tell which revision is the one to use and check earlier ones when they need to understand the history of the process. The same care applies to submittal tracking in general: each revision should stay linked to the one before it, not replace it without leaving a trace.

Transform your construction projects