A Request for Information — an RFI — is the formal way a construction team resolves a question before it becomes a mistake in the field. Someone in the trailer or on the deck finds a gap: a dimension that does not close, a detail the drawings do not show, a conflict between the structural and the mechanical sets. Rather than guess, they write it down, route it to the people who own the answer, and wait for a documented response that becomes part of the project record. This template turns that whole loop — from Field question identified to Update drawings & close — into a living graph you can edit, assign, and connect to your model.
It is built for the people who actually run the RFI log: the general contractor's project engineers and superintendents, the construction manager routing questions to the design team, and the architects and engineers who answer them. Anyone who has watched a simple clarification sit unanswered for three weeks and stall a whole trade knows why the process deserves more than an email chain.
The flow has eight steps and one branch. The happy path runs left to right and top to bottom; a single loop sends an incomplete RFI back to be rewritten. That branch is the part most static flowcharts leave out, and it is where most real delay lives.
How this RFI process template works
Field question identified. The process starts the moment someone on site hits a question they cannot resolve from the contract documents. This is the trigger — a foreman, a superintendent, or a trade partner flags something that needs an official answer before work proceeds.
Draft the RFI. The question is written up formally: what is being asked, why it matters, the affected drawings or spec sections, the location, and — critically — the schedule impact if it is not answered. A well-drafted RFI includes the asker's proposed solution, which speeds the response and reduces back-and-forth.
Submit to GC / CM. The drafted RFI goes to the general contractor or construction manager, who owns the log. Submitting here means the RFI gets a number, a date, and a place in the aging report.
GC logs & reviews. This is the routing hub of the whole process. The GC checks that the RFI is complete, non-duplicative, and actually a design question rather than something the contract already answers. From here the flow can go two ways.
The incomplete branch. If the RFI is missing information, is unclear, or should never have left the field, the GC sends it back with the label incomplete — revise. On the graph this is the edge that loops from GC logs & reviews straight back to Draft the RFI. Catching a weak RFI here — before it burns a review cycle with the architect — is how good teams keep their response times honest.
Forward to design team. A complete RFI is forwarded to the party who can actually answer it — usually the architect, or the specific engineer of record for a structural, mechanical, or electrical question.
Architect / engineer responds. The design team issues a written answer. A good response resolves the question completely, notes any cost or schedule implication, and — where needed — attaches a sketch or revised detail.
Distribute the answer. The GC pushes the answer back out to the trades who need it, and to anyone else the answer affects. An RFI answered but not distributed is an answer that never happened.
Update drawings & close. The resolved answer is folded back into the record — the as-builts, the affected drawings, the coordination set — and the RFI is closed. The question is now part of the project's documented history, which is exactly where it needs to be when someone asks about it a year later.
How to use it in FlowGraph
- Open the template. Click Open in FlowGraph to load the RFI process as a live, editable graph. Viewing and editing are free with no account — you can rearrange the flow and rename steps before you decide to save anything.
- Assign owners. Add the responsible person to each step so the log shows who holds the ball. Put your project engineer on GC logs & reviews, the architect of record on Architect / engineer responds, and the requesting foreman on Field question identified. Now the graph answers the question every RFI meeting asks: whose court is it in?
- Wire to your model. Link an RFI card to the affected element in your IFC or Revit model so the question carries its context. Import an IFC file into FlowGraph and connect the RFI to the exact beam, duct run, or wall it concerns — the answer then lives next to the thing it changes, not in a spreadsheet cell three tabs away.
- Track to closed. Move each RFI through the flow until the answer is distributed and the drawings are updated. Because every change is a governed edit that carries a receipt, the aging and the bottleneck are visible — you can see which RFIs are stuck at Forward to design team and for how long.
- Extend it with AI. With your own AI key you can ask FlowGraph to draft the RFI text from your notes, or to propose which discipline should answer a given question. The AI proposes; you verify and decide. Nothing is written to the log until you accept it.
Why a living graph beats a static RFI log
A spreadsheet RFI log tells you a number and a date. It does not tell you where the question lives in the building, what it depends on, or which trade is blocked waiting for it. Because every card in FlowGraph is a real object — not a cell — you can link an RFI to the model element it concerns, to the submittal it affects, and to the schedule activity it threatens. The relationship is the point of a graph, and construction is nothing but relationships.
Every edit is governed and reversible, and every change carries a receipt: who moved this RFI, when, and why. That provenance is what turns an RFI log from a memory aid into a defensible record — the kind you can stand behind in a claim. When a response is late and a delay is disputed, the honest history is already there, timestamped, rather than reconstructed after the fact.
And the graph grows with you. Ask AI to extend the flow with your firm's specific review gates, duplicate the pattern across a hundred RFIs, or connect the whole log to a live model — all without losing the single, traceable write path underneath. It stays local-first and yours: the template opens with no account, and you only sign up when you want to save it to a vault or plan with AI.
Frequently asked questions
What is an RFI in construction?
A Request for Information is a formal, written question a contractor sends to the design team to clarify drawings, specifications, or field conditions before work proceeds. It is not a casual email — each RFI is numbered, logged, answered, and closed so the answer becomes a permanent part of the project record.
The discipline matters because construction runs on documents, and documents are never perfect. An RFI is how the team fills the gaps between what was drawn and what is actually being built, without anyone guessing.
Who manages the RFI process?
The general contractor or construction manager typically owns the RFI log. They receive field questions from the trades, check them for completeness, forward the legitimate ones to the architect or engineer, and distribute the answers back down to the trades. On this template the GC logs & reviews step is the routing hub where all of that ownership lives.
Assigning that step to a named person in FlowGraph makes the accountability explicit — there is always one owner responsible for keeping the log moving.
How long should an RFI take to answer?
Most contracts set a response window of five to ten working days from receipt by the design team. Long-lead or complex questions may warrant a shorter negotiated turnaround if they threaten the schedule.
Tracking each RFI on a graph makes the aging and the bottleneck visible, so nothing stalls silently. You can see at a glance which questions are approaching their contractual deadline and which trade is blocked waiting — the difference between managing the log and being surprised by it.