Construction RFI and submittal process field guide

RFIs and submittals, the two paper trails that run the job

Two workflows resolve the gaps and the approvals before anything gets built, and they are the ones that decide whether the schedule holds. The RFI asks a question. The submittal proves an answer. An RFI is a request for information, a written question to the design team when the drawings conflict, the spec is silent, or the field does not match the plan. A submittal is the proof that the product, the shop drawing, or the sample you intend to install actually matches what the spec called for, sent in and reviewed before the gear is ordered or fabricated.

Run them well and the job moves. Run them badly and it stalls in two predictable ways. Open RFIs leave the crew guessing or stopped, because nobody will commit to building a wall, a penetration, or a bus run over an unresolved conflict. Late or rejected submittals leave you with no approved gear to order, so the long-lead equipment that drives the whole schedule shows up late or never gets released.

Both feed the rest of the project record. An RFI answer that adds or changes scope becomes a change order, which is its own discipline covered in the field change order guide. The approved submittal and the resolved RFI both land in the daily report when the work that depends on them gets built, and that contemporaneous log is covered in the daily report guide. This guide is about the two workflows themselves: how to write them, how to track them, and how to keep them from becoming the reason the job is behind.

What is an RFI in construction?

An RFI, a request for information, is a formal written question to the design team that gets a tracked answer. It is raised when the contract documents do not give the field a clear, buildable instruction. The three classic triggers are a conflict between drawings or between disciplines, missing or ambiguous information in the plans or spec, and a field condition that does not match what the documents show.

The word that matters is formal. An RFI is not a hallway conversation or a text to the engineer. It is a numbered document that states the question, gets routed to the party responsible for that scope, and comes back with a written answer that becomes part of the contract record. That paper trail is the point. When the answer changes the work, or when a delay traces back to how long the answer took, the RFI is the evidence.

An RFI is also not a complaint and not a substitute for reading the documents. If the answer is already in the spec, the design team will send you back to the spec, and you have spent a week of turnaround proving you did not look. The good ones surface a real gap and propose how to close it. The General Conditions of the contract, often an AIA or ConsensusDocs form, set out how requests for information are handled and what response time the design team owes, so check what your contract actually says before you assume a deadline.

What makes a good RFI

A good RFI asks one question and proposes the answer. That is the whole discipline. One question, because a single RFI with five questions buried in it comes back partly answered or sits while the reviewer waits to address all of it at once. A proposed answer, because the fastest response a designer can give is to agree with a resolution you already worked out, drew up, and put in front of them.

Propose the answer. This is the part crews skip and it is the part that gets you a same-week response instead of a three-week one. Do not write "the drawings conflict, please advise." Write "Drawing E-401 shows the feeder routed through the wall that A-201 shows as rated. We propose routing the feeder above the corridor ceiling per the attached sketch, which keeps the rated assembly intact. Please confirm." Now the designer is checking your work, not starting from a blank page.

Around the question, give the reviewer everything needed to answer without a second round. A photo of the field condition. A sketch or a marked-up drawing showing the proposed fix. The exact spec section and drawing references so they are not hunting. And a date needed by, tied to the schedule, so the request carries its own urgency. An RFI with the photo, the sketch, the references, and the proposed answer is one the design team can close in a single pass. An RFI without them is a conversation that takes weeks.

What a bad RFI looks like

A bad RFI is vague, asks several questions at once, proposes nothing, and reads like fishing. "Please clarify the electrical room layout" is not a question anyone can answer cleanly, so it comes back as another question, and the clock has already run. Each round trip is days or weeks you do not get back.

Multiple questions in one RFI are the common version of this. They feel efficient and they are the opposite. The reviewer answers the two easy ones, holds the hard one, and the whole RFI shows as open while you wait on the part you actually needed. Split them. One question per RFI, even if you fire off four at once, so each can close on its own timeline.

Fishing is the worst version, and design teams recognize it fast. An RFI sent to manufacture a delay, to create a paper basis for a claim, or to push a design decision onto the engineer that the contractor should own, slows every legitimate request behind it because it teaches the reviewer to read your RFIs with suspicion. Ask the real question, propose the real answer, and keep the channel clean. The reputation of your RFI log is an asset, and a few fishing expeditions spend it.

The RFI log

The RFI log is the running register of every request, its status, and its impact, and it is the single document that tells you whether the question side of the job is under control. Every RFI gets a number, a date sent, a needed-by date, the responsible reviewer, a status, and a note on whether the answer carries a cost or schedule impact. Without the log you have a pile of emails and no way to say what is open, what is late, and what is holding up the field.

The columns that earn their keep are the dates and the impact. Date sent and needed-by give you the aging, which is the number that actually drives action. The status tells you where it sits: open, answered, answered with a scope change, or closed. The cost and schedule impact column is the one crews forget, and it is the one that ties the RFI to the change order and the delay record. An answered RFI that added scope is not closed until the change order is in.

Keep one log for the project, not one per person and not one per email thread. The value of the log is that it is the single place anyone can look to see the state of the open questions. Scatter it across inboxes and you lose the aging, you lose the count, and you find out a critical RFI has been open for a month when the foreman is standing at the wall with no instruction. A shared field tool that holds the log, the status, and the aging in one place is the difference between managing the RFIs and discovering them.

Why does an open RFI stall the work?

An open RFI stalls the work because the field will not, and should not, build over an unresolved question. Until the conflict is answered, the wall does not go up, the penetration does not get cored, the bus run does not get set. So the number that matters on the RFI log is not how many you have sent. It is how long the open ones have been sitting.

Track the aging. The day an RFI is sent, the clock starts, and you watch the count of days open against the needed-by date. The contract usually gives the design team a response window, often in the range of one to two weeks depending on the form and the project, so confirm the number in your General Conditions rather than assuming it. When an RFI crosses its needed-by date or its contractual window, it is stale, and a stale RFI is a stopped activity on the schedule whether or not anyone has flagged it yet.

Escalate the stale ones, on a cadence, in writing. A weekly RFI report that lists every open request, sorted by age, with the schedule activity each one is holding, turns a quiet problem into a visible one. That is also the record that protects you. If an RFI sat open past its window and the work it gated slipped, the dated log showing when you asked and when they answered is the basis for the time you are owed. The aging is both your management tool and your delay evidence.

When an RFI answer becomes a change order

An RFI answer that changes the scope is a change order, and you do not build the extra for free. This is the single most expensive miss on the RFI side of the job. The answer comes back, it directs more or different work than the contract drawings showed, the field reads it as an instruction and builds it, and three weeks later the office tries to bill work that was never priced or signed.

Read every RFI answer for scope before you act on it. If the resolution is a clarification that costs nothing more than the base contract already covered, build it. If the resolution adds material, labor, or time, or changes a means and method in a way that costs you, stop and price it. The RFI answer is the trigger and the basis, but it is not authorization to perform changed work. The change order is.

The clean sequence is RFI answer, then notice of a change, then a priced change order, then build. The field change order guide covers the takeoff, the markup, and the signatures that turn that scope into a number on the pay application. The link to hold onto here is that the RFI log and the change order log talk to each other: the impact column on the RFI log is where a scope-changing answer gets flagged so it does not slip through as free work. Answer it, price it, sign it, then pour it.

What is a submittal in construction?

A submittal is proof that the product, the shop drawing, or the sample you intend to install matches the specification, sent to the design team for review before the item is ordered or fabricated. Where the RFI asks a question, the submittal answers one the spec already posed: does what you are buying actually meet what we required? The submittal is how that gets checked on paper before money is spent and steel is cut.

The point of the timing is to catch the mismatch before it is expensive. A light fixture that does not meet the spec is a cheap fix when it is a line on a product data sheet under review. It is a very expensive fix when 600 of them are on a truck. Submittals move the catch upstream, to the point where the answer is a markup instead of a return-to-vendor.

The submittal also creates the record of what the design team approved you to install. Once a submittal is stamped, the field builds to the approved submittal, not to the original catalog cut or the sales rep's promise. That approved set becomes the reference for installation, for inspection, and eventually for closeout. The General Conditions and the spec's submittal procedures section, commonly the 01 33 00 range in the CSI MasterFormat numbering, define what has to be submitted and how it is reviewed, so the contract and the spec control the list, not habit.

The main types of submittal

Submittals come in a handful of recognizable types, and the spec tells you which type each item needs. Product data is the manufacturer's literature, the cut sheets and catalog pages that show a stock item meets the spec. Shop drawings are drawings prepared for this project, by the fabricator or the contractor, showing how a custom assembly will actually be built and how it fits the field. Samples are physical pieces, a length of conduit, a finish chip, a section of louver, when the spec wants the real thing in hand.

Mockups go further than samples. They are a built-to-scale assembly, a section of wall or a typical equipment skid, used to confirm the look, the fit, and the means of construction before the real thing is replicated across the job. On a data center, a power skid or a rack lineup mockup catches coordination problems once instead of a hundred times.

Closeout submittals come at the other end. Operations and maintenance manuals, warranties, spare parts, and the as-built record are submittals too, due near the end and feeding the owner's turnover package. Treat them as part of the same workflow from the start, because a closeout submittal that nobody assembled until the last week is how substantial completion slips while everyone waits on a binder.

What is a submittal register?

A submittal register is the master list of every submittal the spec requires, organized by spec section, tracked against its review status and, the part that makes it powerful, tied to the procurement lead time. It is built at the start of the job by reading the specification section by section and pulling out every item that calls for a submittal, then mapping each one to when it has to be approved so the gear can be ordered in time to arrive when the schedule needs it.

The register is where the submittal workflow stops being reactive. Without it, submittals get sent when somebody remembers, which is usually when the foreman needs the gear. With it, you work backward from the install date: install date, minus the manufacturing and delivery lead time, minus the review time, gives you the date the submittal has to go out. Miss that date and the equipment is late no matter how fast everyone moves afterward.

Sort the register by lead time, not by spec number, when you are deciding what to work first. The 26 series electrical gear and the 23 series mechanical equipment usually carry the longest lead times and the most schedule risk, so they get submitted first even though they sit late in the spec book. The register tied to the schedule is what turns a list of paperwork into a procurement plan, and it is the document the project manager lives in.

Long-lead equipment: submit first or the schedule slips

Submit the long-lead gear first, because on a large project the schedule is set by procurement, not by labor. Switchgear, generators, large UPS modules, chillers, transformers, and custom busway can carry lead times measured in many months, and on a tight market those numbers stretch. The submittal for that equipment is the first domino. Until it clears review, the order is not released, and until the order is released, the lead-time clock has not even started.

Front-load these the day the job starts. The most common, most damaging schedule mistake on the submittal side is treating the long-lead items in spec order instead of lead-time order, so the gear that needed to be submitted in week one goes out in week eight, and you have given away weeks you will spend the rest of the job trying to claw back. There is no recovering a lead time you did not start. You can expedite, sometimes, at a price, but you cannot un-spend the calendar.

On a data center this is the whole game. The mechanical and electrical equipment that delivers the megawatts is exactly the long-lead, custom, schedule-driving gear, and the date the building can be energized traces straight back to when those submittals cleared and the orders dropped. Get the long-lead submittals approved early and the rest of the job has room. Get them approved late and every trade behind them is compressed into whatever calendar is left.

What do submittal review stamps mean?

The review stamp is the design team's verdict on a submittal, and the four common results each mean something specific for whether you can order and build. Approved means the submittal meets the spec and you may proceed. Approved as noted means proceed, but incorporate the reviewer's markups, and you do not have to resubmit before ordering. Revise and resubmit means it is not acceptable as sent, fix the noted items and send it back through review. Rejected means it does not meet the spec, start over.

Read the exact wording on the stamp, because the labels vary by reviewer and by contract and the consequences differ. The line that catches people is the boilerplate that says review does not relieve the contractor of responsibility for meeting the contract documents. That is real. An approved submittal that turns out to deviate from the spec is still your deviation to fix. The stamp confirms general conformance, it does not transfer responsibility for the details.

The status that matters most for the schedule is the difference between approved as noted and revise and resubmit. Approved as noted lets you order now. Revise and resubmit sends you back to the start of the review clock. On a long-lead item, that distinction can be weeks of procurement, which is why a clean first submittal is worth real effort.

The revise-and-resubmit loop

Every rejection restarts the clock. That is the cost of a sloppy first submittal, and it is why getting it right the first time is worth slowing down for. A submittal that comes back revise and resubmit goes to the bottom of the reviewer's stack on the next pass, and the review window starts over, so a five-day review you could have closed once becomes ten or fifteen days across two or three rounds.

The churn compounds on long-lead gear. The equipment with the longest lead time is usually the equipment with the most complex submittal, the most coordination, and the most chances to get a markup. Two rounds of revise and resubmit on a piece of switchgear is not a paperwork annoyance. It is weeks added to the front of a multi-month lead time, and it lands on the critical path.

Cut the loop by reviewing the submittal before it goes out. The subcontractor or vendor prepares it, but the contractor's own review, against the spec, against the field dimensions, against the coordination model, catches the obvious deviations before the design team ever sees them. A submittal that arrives clean and complete gets one pass. A submittal padded out to look complete but missing the data the reviewer needs gets sent back, and you own the time.

Deferred and delegated design submittals

Some systems are not fully designed by the engineer of record. The contract sets the performance criteria and assigns the actual design to a licensed professional the contractor hires, who stamps it. Fire sprinkler layouts, seismic bracing, precast connections, and some structural and equipment-support designs are the usual examples. These come in as delegated design submittals, and the deferred ones are reviewed and permitted after the main building permit.

The detail that controls these is the professional engineer's stamp. A delegated design submittal carries the seal and signature of the design professional responsible for it, and the engineer of record reviews it for conformance with the design intent, not for the internal calculations, which are the delegated engineer's responsibility. Confirm what your spec and the building department require, because the deferred-submittal rules are set by the authority having jurisdiction and the contract, and they vary.

Treat the deferred items like long-lead items on the register, because they are. They need a designer engaged, calculations run, a stamp applied, and a separate review and permit cycle, and all of that takes time the schedule has to account for from the start.

Or-equal and substitution requests

When you want to install something other than the specified product, the burden is on you to prove it meets the spec, and there are two paths. An or-equal request proposes a product the contractor considers equal to the one specified, usually without changes to adjacent work, and the spec often gives a short window after the notice to proceed to submit these. A substitution request is the broader case, where the proposed item differs enough that it needs a fuller comparison and the design team's evaluation.

Either way, prove it. A substitution submitted as "this one is just as good" gets rejected on sight. The one that gets approved lays the proposed product next to the specification line by line, shows where it meets each requirement, flags any deviation honestly, and addresses the knock-on effects on connected work, dimensions, and warranties. The reviewer is deciding whether your alternate carries a hidden cost the owner would inherit, so the submittal that answers that question up front is the one that clears.

Watch the deadline and the basis. The contract usually limits when substitutions can be proposed and may require the contractor to cover the design team's cost of reviewing them. Read the substitution procedures in the spec before you build a request around saving a few dollars on a product, because a late or sloppy substitution wastes review time you could have spent getting the specified item approved.

Who routes an RFI or a submittal

Both workflows run up a chain and back down it, and knowing the chain tells you where a stuck item is sitting. The standard route runs from the subcontractor to the general contractor to the architect or engineer, and the answer comes back the same way in reverse. The sub raises it, the GC reviews and forwards it, the design professional responsible for that scope reviews and responds, and the answer returns down the chain to the field.

The general contractor's review in the middle is not a rubber stamp. The GC checks the submittal or RFI for completeness, for coordination with other trades, and for whether it is even the design team's question to answer, before it goes up. A request that the GC forwards without that review wastes a round trip when the design team sends it back for the information the GC should have caught. On a large job a dedicated project engineer owns this review, because it is constant.

Know which design professional owns each item, because routing to the wrong one burns the review window. The electrical RFI goes to the electrical engineer, the structural submittal to the structural engineer, and a coordination conflict between them may need both. The contract names the parties and the routing, and on a fast job the routing being clean is half the speed.

Distribution and building to the approved set

An approved submittal is only worth something if the field gets it and builds to it. Once a submittal comes back approved or approved as noted, it has to be distributed to the people who will install the work, with the reviewer's markups incorporated, so the crew is building to the reviewed version and not to an old cut sheet or a superseded shop drawing. The gap between approval and the field having the approved set in hand is where wrong gear gets installed against a stale document.

Coordinate the approved information with the rest of the work as it lands. An approved equipment submittal carries dimensions, clearances, connection points, and weights that the other trades have to design around, so the approved data feeds back into the coordination model and the field layout. A chiller approved at a different footprint than the plan assumed is a coordination problem that has to be caught at submittal, not at the housekeeping pad.

When the work that depends on a submittal or a resolved RFI gets built, that is what lands in the daily report. The daily report guide covers why the contemporaneous log of what was built, by whom, and under what conditions is the record that wins disputes. The approved submittal is what the daily report points back to when the question later is whether the installed work matched what was approved.

How RFIs and submittals feed closeout

The submittal workflow does not end at approval. It ends at turnover, because the closeout package is built from submittals. Operations and maintenance manuals, equipment warranties, spare parts, and the as-built record are all submittals due near the end of the job, and they assemble from the product data and shop drawings that were approved along the way.

Keep the approved submittals organized as you go, because the closeout binder is the approved product data, the final shop drawings, and the warranty documents pulled together for the owner. A job that filed its submittals cleanly during construction assembles closeout in days. A job that has to reconstruct what was actually installed, from scattered emails and a foreman's memory, drags substantial completion while everyone hunts for paper.

The as-built record ties it together. The RFIs that changed a routing, the submittals that fixed a product, and the field changes that moved a wall all have to land in the as-builts so the owner has an accurate record of what is actually in the building. That record is the one the next contractor, the facilities team, and the commissioning agent will rely on for the life of the building.

RFIs and submittals at data center scale

On a large data center, the RFI and submittal counts run into the thousands, and the volume itself becomes a management problem. A fast-track job that is being designed while it is being built generates RFIs continuously, because the documents the field is working from are not finished. A multi-building campus has a submittal register hundreds of lines long per building, and the same equipment package repeats across data halls, so a single submittal problem multiplies.

The thing that makes a data center different is that procurement drives the megawatts. The schedule is not labor-limited, it is gear-limited, and the gear that delivers power and cooling is the longest-lead, most custom, most submittal-heavy equipment on the job. The date the building energizes traces directly back to when the switchgear, the generators, the UPS, and the chillers cleared submittal review and the orders were released. Everything downstream, the install, the terminations, the integrated systems testing, the commissioning, sits behind that.

At this scale the discipline is the same as on a small job, applied without exceptions. Propose the answer on every RFI. Track the aging so nothing critical sits. Front-load the long-lead submittals. The difference is that on a small job a slip is recoverable and on a data center a slipped long-lead order moves the energization date for an owner counting the cost in megawatts per month.

How do you track RFIs and submittals?

Track RFIs and submittals in one system that holds the status, the aging, and the impact, not in scattered email threads. The failure mode is the same on both workflows: when the record of what is open and how old it is lives in people's inboxes, nobody can answer the basic question of what is holding up the job, and a critical item sits open until a foreman is standing at the work with no instruction.

One system means one RFI log and one submittal register that everyone reads from. For each RFI: the number, the dates, the responsible reviewer, the status, and the cost or schedule impact. For each submittal: the spec section, the type, the lead time, the dates, the review stamp, and where it sits in the register tied to the schedule. The value is the single source of truth and the automatic aging, so the stale items surface before they bite instead of after.

FieldOS keeps the field side of this in one place, capturing the RFI, the photo and sketch that go with it, and the status, so the question is logged where the work is and the aging is visible from the field, not buried in an inbox. The tool matters less than the discipline, but the discipline is nearly impossible to hold across thousands of items spread over a dozen inboxes. One system, one log, one register, read by everyone.

Common mistakes

• Sending a vague RFI with no proposed answer, so it comes back as another question and the clock runs.
• Not tracking RFI aging, so a stale request quietly stops a schedule activity until someone notices at the wall.
• Building an RFI answer that changed the scope without a change order, and eating the cost as free work.
• Submitting long-lead gear in spec order instead of lead-time order, so the schedule-driving equipment goes out late.
• Revise-and-resubmit churn from a sloppy first submittal, restarting the review clock on the critical path.
• Tracking RFIs and submittals in scattered emails, so nobody can say what is open, how old, or holding what.

What to document

Both workflows live or die on the record, and the record is only useful if it is one place, current, and tied to the schedule. The RFI log and the submittal register are the two documents that have to be real and shared. Each captures a different thing, but both answer the same question for the person reading them later: what was open, when, and what did it hold up.

Field checklist

Standards and references

The contract is where the RFI and submittal rules actually live, so start there. The General Conditions, commonly an AIA form such as A201 or a ConsensusDocs equivalent, set out how requests for information and submittals are handled, who reviews them, what response times apply, and how a change in the work is authorized. The exact provisions and time frames vary by form, edition, and the project's supplementary conditions, so read the contract documents on your job rather than relying on a general rule.

The specification controls the submittal list and procedures. Under the CSI MasterFormat numbering, the submittal procedures are commonly in the 01 33 00 range of Division 01, and each technical spec section lists the submittals required for that scope, the product data, shop drawings, samples, and closeout items. The substitution and or-equal procedures, and the deferred and delegated design requirements, are also set in the spec and the General Conditions, with deferred submittals additionally governed by the authority having jurisdiction.

The project schedule is the third reference, because it is what the submittal register is tied to and what the RFI aging is measured against. The three rules that hold across all of it: propose the answer in every RFI, track the aging and front-load the long-lead submittals, and turn an RFI answer that changes scope into a change order. The contract documents and the spec govern the specifics; these three keep the job from stalling on open questions and rejected gear.

Terms and definitions

The RFI and submittal workflows carry a vocabulary that shows up across the contract, the spec, and the review software, and the same item can read differently from one document to the next.

RFI

Request for information, a formal tracked question to the design team about a conflict, a gap, or a field condition

Submittal

Product data, shop drawing, sample, or mockup sent to prove an item meets the spec before it is ordered or fabricated

Submittal register

The master list of required submittals by spec section, tied to review status and procurement lead time

Long-lead item

Equipment with a long manufacturing and delivery time, such as switchgear, generators, or chillers, that drives the schedule

Approved as noted

A review stamp allowing the work to proceed with the reviewer's markups incorporated, without a resubmittal

Revise and resubmit

A review stamp returning a submittal for correction, which restarts the review clock

Delegated design

A system designed by a licensed professional the contractor hires, submitted under that engineer's stamp

Or-equal / substitution

A request to install a product other than the one specified, with the burden on the contractor to prove it meets the spec

Related tools

Calculators and readiness checks for this work

Compare your options

FAQ

People also ask

• What goes in a construction daily report?
• What is a field change order?
• How is a data center built?
• What is an inspection and test plan?
• Cast-in vs post-installed anchors: which should I use?