RFIs

Raising, reviewing, and returning Requests for Information with a clear record for every question.

Overview

An RFI is a formal request for clarification when the contract documents contain missing, conflicting, or unclear information. It should identify one focused question and reference the relevant drawings, details, and specification sections. On Procore-connected projects, see also Procore-Connected RFIs.

What an RFI is, and where it lives

An RFI is one question and its answer, with everything needed to make the answer defensible attached to it: what was asked, which documents it concerns, who was consulted, what each of them said, and what the architect formally replied. LiveArch treats the question and that record as one object — an RFI is not a message you send, it is a record that moves.

The discipline that makes this work is one focused question per RFI. An RFI that bundles three unrelated questions cannot be assigned to the right reviewers, cannot be answered in one reply, and leaves no clean record of which part was actually resolved. Reference the specific drawing, detail, and specification section rather than describing the location in prose.

The record has a state at all times, and it is always someone's turn. That is what makes the list views, the ball-in-court, the review-progress bar, and the notifications possible — none of them are separate bookkeeping, they are all readings of the same state.

Standalone or Procore-connected

The review is identical either way. What differs is where the RFI is born and where the answer has to end up.

On a standalone project, the RFI is raised in LiveArch, reviewed in LiveArch, and the finalized reply is issued from LiveArch. LiveArch is the only system of record.
On a Procore-connected project, the RFI is raised in Procore and assigned to the integration user, then arrives in LiveArch already issued — it enters at Pending, skipping Draft. The review runs in LiveArch, and the finalized reply is returned to Procore. Once a reply has been sent to Procore it is permanently read-only in LiveArch.

Connected projects have their own page for the assignment rules and the return trip: Procore-Connected RFIs. Everything on this page applies to both kinds of project unless it says otherwise.

How an RFI moves

Every RFI moves through five stages: Draft (being authored), Pending (awaiting distribution — where Procore-assigned RFIs arrive), Open (collecting responses), Reviewed (input in, formal reply not yet issued), and Finalized (official response issued). Three backward moves exist, all deliberate admin actions: a Reviewed RFI can be reopened for more review, an Open RFI nobody has responded to yet can be returned to Pending, and a Pending RFI can be pulled back to Draft. A Procore-linked RFI stops at Pending, since its question is authored in Procore.

Full RFI lifecycle — Draft, Pending, Open, Reviewed, and Finalized, with the CM issuing, the architect distributing and composing the formal reply, consultants reviewing, and Procore-linked RFIs entering at Pending via webhook with their finalized response returned to Procore — The same five stages apply whether the RFI started in LiveArch or arrived from Procore — a Procore-linked RFI just enters at Pending and requires one extra step to return its response to Procore.

The list and the record page word the same state differently — the list compresses, the record page is precise:

In the list	The record page says	Find it under	What's happening
Draft	Draft	Drafts	Being authored — whoever raised it still holds it.
Pending	Awaiting Distribution	Pending	Received but not yet sent to reviewers — the architect still has to build the reviewer list. Waiting on the design team, not the reviewers.
Open	Collecting Responses	All Open / My Open	The only stage where reviewers act — where the review-progress bar and the overdue and stagnant flags do their work.
Reviewed	Awaiting Finalization	Returned	Reviewer input is in; the architect has not yet issued the formal reply. Reached when the last reviewer responds, or when the architect closes review early.
Finalized	Response Finalized	Returned	Terminal — the only stage that contains an official answer. Everything before it is coordination history.

Once an RFI is distributed, LiveArch keeps it moving without anyone having to check in manually: reviewers are notified the moment it's their turn, the architect is notified once every reviewer has responded, and the submitting party is notified — and, on a connected project, Procore is updated — as soon as the finalized response goes out.

A new question is a new RFI. Revising an existing RFI creates a new revision of that record, not a fresh number — and it is not the way to ask something the finalized reply did not cover.

Create a standalone RFI

Open RFIs, select New RFI, and enter the next sequential number the project requires. Give the RFI a concise title, describe the conflict, omission, or question, and reference the applicable drawing, detail, and specification section — including the CM/GC's suggested solution when appropriate. Attach the required transmittal and clearly named supporting drawings, photographs, measurements, or product information, then submit the RFI for the architect's completeness check and distribution.

The CM/GC should review subcontractor questions before submitting them. An RFI is also not the vehicle for a substitution or contract-scope change that the project documents route through another process.

Drafts

An RFI you start but don't submit right away is saved to Drafts, sorted by when it was last updated rather than by number — most drafts don't have one yet. Reopen a draft with Edit, or delete it if it's no longer needed.

Priority

Every RFI carries a priority — Critical, High, Standard, or Low. Priority is informational only: it flags workload, it doesn't change how quickly a response is due. Response timing follows the project's contractual allowances regardless of the priority set on the record.

Video: Creating a new RFI (~30 sec)

Numbering, the question, document references, attachments, and drafts.

Distribute, review, and finalize

Distributing

From Pending, the architect builds the reviewer list — typically from a reviewer group — orders it, and sends the RFI out. Distribution is what opens the RFI for review.

Video: Distributing for review (~30 sec)

Build the reviewer list from a reviewer group, order it, and send it out.

Responding as a reviewer

Open an assigned RFI to read the original question, every referenced document, and the history of any earlier reviewer input. Enter your response, attach supporting files if needed, and submit — the architect can send a reminder if a reviewer is running behind.

Video: Reviewing and responding (~30 sec)

Read the question and the prior input, attach support, and submit a reviewer response.

Finalizing

Once every reviewer has responded, the architect composes the formal reply — pre-filled from the collected reviewer input — selects a response type (Answered, Refer to Documents, Clarification Needed, or Void), chooses which reviewer attachments to carry into the final reply, and finalizes it. On a connected project, finalizing and sending to Procore can happen in one step. Once a finalized reply has been sent to Procore, it's permanently read-only in LiveArch. Reviewer input remains part of the coordination history — the architect's finalized response is the official response unless the project procedure states otherwise.

Video: Finalizing the reply (~30 sec)

Compose the formal reply from the collected input, pick a response type and attachments, and finalize.

Everything else on the record

The record's sidebar keeps the rest of the history in one place: prior revisions, the full activity log, and — on a connected project — the linked Procore record and its sync status. You can also export any RFI to PDF from the question card.

Track status and notifications

The RFI list is organized into views along the top — All RFIs, Pending, All Open, My Open, and Returned — each showing a live count. From there:

Search opens a dedicated search across subject, question text, and reviewer responses — not just what the current view happens to show.
Filters combine conditions — status, priority, ball-in-court company, stage, dates, and quick toggles like overdue or stagnant — to narrow the list to exactly what you need.
Group By reorganizes the list under Status, Priority, Ball in Court, or Stage instead of one flat table.
Export Report downloads the current view — respecting its filters, grouping, and visible columns — as a spreadsheet. Larger exports are emailed as a link instead of downloading immediately.

Each row's Review Progress column is a quick read on where a record stands — the bar fills as the review period elapses, small segments mark each reviewer's place in the chain, and trailing text gives the exact count in days. A few examples:

Review Progress indicator immediately after distribution — an empty bar with the marker at the far left, and all four reviewer segments light grey — Just distributed — nothing filled yet.

Review Progress indicator partway through review — the bar partly filled, completed reviewer segments dark and the rest light, everything shown in grey while on track — On track — completed reviewers turn dark.

Review Progress indicator in a stalled state — the bar red with a plus mark for overdue, a yellow reviewer segment for a reviewer holding it too long, and bold red days-overdue text — Stalled — overdue turns the bar red; a slow reviewer's segment turns yellow.

Review Progress indicator once finalized — the bar full in dark grey, every reviewer segment dark, and the days text muted; a plus mark can still appear if the review finished after its due date — Finalized — all dark; the plus mark stays only if it finished late.

Video: Finding things (~30 sec)

Move between the views, combine filters, search question text and responses, group, and export.

Video: Admin tools (~30 sec)

Reminders, closing review early, reopening for more review, and the record sidebar.

LiveArch emails your company for RFI events, including:

A new RFI is distributed naming your company as a reviewer, or copying your company on the distribution list.
Another party completes their review and your company becomes the ball-in-court party.
Review is complete and your company is listed as Notify on Return.

Coordinate with the BBB project team to configure which users at your company receive these notifications — see Settings.

Who does what

These terms are the ones most often confused, because more than one can apply to the same record at once. The distinction that matters: is this person expected to act, or just being kept informed?

Term	Expected to act on the record?	Notes
Assignee	Yes	The current Procore-side owner of an RFI.
Reviewer	Not necessarily	Contributes comments, markups, or a response during review — not always the architect's final formal response.
Reviewer group	—	A reusable, ordered collection of reviewers, often organized by specification section or discipline.
Ball in court	Yes	The general term for whoever's turn it is next, in either platform.
Distribution list	No	Copied or notified only — not given responsibility for the record.

Support

Questions or issues? We're happy to help — , or use the contact form if you're signed out.