RFIs

A Request for Information (RFI) is the way a question on site gets a documented, attributable answer. Where defects track "this needs fixing" and work orders track "this is engaged for repair," RFIs track "we need a decision before we can proceed."

Instead of losing design questions in email, every RFI in IssuesId is a threaded, searchable conversation linked back to the drawing, defect, or stakeholder it relates to.

The lifecycle

RFIs move through three states:

01Open — raised, awaiting a response.
02Responded — an answer has been posted to the thread.
03Closed — the question is resolved and the answer is on record.

A closed RFI can be re-opened if new information emerges or the answer turns out to be incomplete — the thread continues from where it left off, with the re-open itself recorded.

Raising an RFI

From a defect, a drawing pin, or the RFI inbox:

→Add a subject and a clear question.
→Attach drawings, photos, or documents that frame the problem.
→Pick the recipient — a named user, a role, or a contractor.
→Set a due date if the answer is time-critical.

The RFI lands in the recipient's inbox. They're notified by email (and in-app if they're online).

Threaded conversation

Every reply, attachment, and status change lives in the RFI thread. The thread is the audit record:

→Who asked.
→Who answered.
→What was attached at each step.
→When each message landed.

Threads support attachments inline — drop a marked-up drawing or a photo and it lives with the message, not in a separate folder somewhere.

Filtered views

The RFI inbox splits into the views you'd expect from any threaded system:

→Inbox — RFIs sent to you, awaiting your response.
→Sent — RFIs you've raised.
→Drafts — RFIs you've started but not yet sent.
→Trash — soft-deleted RFIs (recoverable).

Each view is scoped by your role, so you're never wading through other people's traffic.

Linking to defects and drawings

An RFI raised from a defect carries that defect's ID and location forward. An RFI raised from a drawing pin carries the drawing reference and the pin coordinates. The link is bidirectional — open the defect later and the related RFI appears in its history.

This is the trail that matters when a defect close-out depends on a design decision: the defect record points at the RFI, the RFI points back at the defect, and both have full thread evidence.

RFIs or Correspondence?

Both are threaded, and both end up as evidence, so the line between them is worth drawing.

An RFI is directed. It has a recipient who owes you an answer, a due date, and a Responded state — the whole shape is built around waiting on a decision before work can proceed.

Correspondence is formal. Threads carry a COR-### reference, a managed participant list including people outside your company, and an explicit send-and-log step. It's for establishing a position on record — a delay notice, a variation, a claim — rather than asking a question.

If you're waiting on an answer, raise an RFI. If you're putting something in writing, open a correspondence thread.