RFI and submittal logs for architects: fields, statuses and response times (with a Notion build)

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

Last reviewed: 30 October 2026. This is general practice information; contract terms and procedures differ, so follow your own contract and local practice.

An RFI (request for information) is a question from the contractor or a subcontractor about the contract documents: a clash, an omission, an unclear detail. A submittal is something the contractor sends for review before using it: shop drawings, samples, product data. A change record (variation, change order or architect's instruction, depending on region) formalises a change to scope, cost or time.

This is an architect-side view. Many popular templates are written for contractors and mix these things together, which is why the separate-logs rule below matters.

Why keep RFIs, submittals and changes in separate logs?

Each has a different owner, deadline and outcome. An RFI answer may reveal a change; a submittal rejection may delay an order; neither is itself a variation. If they sit in one list, filters stop working and the one that carries cost gets lost among queries.

Link instead of merging: give each RFI a relation to the change it triggered and the drawing revision that answered it. That creates a trail without blurring the records.

Which fields should an RFI log have?

What status flow works for RFIs?

1. 1

   Received

   Logged, numbered and acknowledged to the sender. Owner: administrator.

2. 2

   In review

   Assigned to the reviewer; consultants consulted if needed. Owner: reviewer.

3. 3

   Answered

   Response sent in writing. Owner: reviewer.

4. 4

   Action needed

   Response requires a drawing revision, instruction or change record. Owner: architect.

5. 5

   Closed

   Answer implemented and contractor confirmed. Owner: administrator.

Add a Rejected / returned state for duplicate or incomplete RFIs that the contract allows you to bounce. Review anything in Received or In review that is past due at each weekly site meeting.

How do you calculate due dates and response times?

The response period is set by your contract or project procedures. Some standard forms state a period and some leave it to be reasonable, so I cannot give a universal number; check yours and apply it consistently.

In Notion, add a Number property "Response days" and a Date property "Received", then a formula for Due date: dateAdd(prop("Received"), prop("Response days"), "days"). Add a formula Overdue: if(and(prop("Status") != "Closed", prop("Due date") < now()), "Overdue", ""). If your contract counts business days only, add a note, or use a manually entered due date.

Worked example: an RFI received Monday 4 May with a five-day period is due Saturday 9 May on calendar days. If the contract counts working days, it is due Monday 11 May. Write the counting rule beside the property so the whole team uses the same one.

Track average days to answer by month; a rising figure shows the review step, not the contractor, is slowing the job.

How do you build the logs in Notion?

1. Create a database called RFIs with the fields above and a relation to Projects.
2. Create Submittals with fields: number, revision, spec section, trade, date received, reviewer, due date, outcome, and status. Submittals revise (rev A, B), so log each revision as a separate entry linked to the first.
3. Create Changes with number, source RFI or submittal, description, cost, time, client approval status.
4. Build views: Open RFIs by due date, Overdue, By trade, By reviewer, Closed this month.
5. Link the RFI to the sheet in your drawing register so a revision answers it.

Notion does not send notifications to contractors, enforce workflow or hold formal document control. If your contract or jurisdiction requires a controlled system, use that and keep Notion as your internal tracker.

Where ArchitectOS fits

Disclosure: we make ArchitectOS, a $39 one-time Notion template, so weigh this accordingly. It does not include dedicated RFI or submittal databases. It does include Drawings, Approvals, a Projects database and a Template Vault, so a practical approximation is to use Drawings for sheets and revisions, Approvals for submittal and change sign-off, and add RFI and submittal tables with the fields above.

It is a template, not document-control software.

• See what's inside ArchitectOS
• ArchitectOS pricing

• Drawing register in Notion
• Decisions log for architects
• Construction administration workflow
• Notion vs Procore for civil engineers

Frequently asked questions

What is an RFI in architecture?

A request for information is a written question from the contractor or a subcontractor about the contract documents, such as a conflict, gap or unclear detail. The architect or consultant answers in writing, and if the answer affects cost or time it should go through a change process.

What is the difference between an RFI and a submittal?

An RFI asks a question about the documents. A submittal sends products, samples or shop drawings for review before use. Different documents, deadlines and outcomes, so log them separately and link them where they relate.

How long does an architect have to respond to an RFI?

It depends on the contract. Some forms state a number of days and others require a reasonable time, so check your own agreement and project procedures. Record the period in your log and calculate due dates from the received date.

Can Notion replace RFI software?

For tracking and internal visibility, a well-built Notion database works for small practices. It does not offer formal document control, contractor portals or enforced workflows. Larger or contract-mandated projects may need dedicated software, with Notion alongside.

Should an RFI become a change order?

Only if the response changes scope, cost or time. Flag possible impact on the RFI, then raise a separate change record that the client approves. Never treat the RFI answer itself as authority to proceed with extra work.