Construction RFI automation: turn field questions into reviewable requests

The existing construction management platform should remain the official record. Autodesk documents RFI stages covering drafting, submission, review, answering, and closure, with an enhanced workflow that adds coordination and expert review. That structure provides a useful boundary: an automation can help prepare and route a question without taking over every stage. Autodesk RFI workflow documentation

Before implementation, I would ask the project manager to identify who can submit an RFI, who coordinates responses, who can designate the official answer, and who can close the record. Those permissions may vary by project or contract. A workflow copied from another project should not silently carry its authority with it.

I would also distinguish an RFI from a change request, submittal, safety report, and ordinary field note. The system can suggest a category, but uncertainty should produce a review task. Routing a safety concern into an ordinary RFI queue could delay the response it needs.

The intake form should capture project identifier, location, discipline, question, supporting files, referenced drawing or specification, and the requester's identity. If the request mentions a date or possible cost impact, preserve it as a reported concern. Do not convert it into an approved schedule or cost change.

Each source attachment should retain its original identifier and receipt time. Photographs need a connection to the question they support. A photo without location or orientation can be useful evidence, but the model should not invent those details to make the packet look complete.

The first automated check should verify required fields against the project's rules. If the question references a drawing that is missing or ambiguous, ask for clarification. The most useful output may be a precise request for one missing reference rather than a polished paragraph based on an assumption.

I would resolve drawing references against the project's approved document register. Store both the revision cited by the requester and the revision found in that register. If they differ, show the difference and require a reviewer to decide how to proceed.

This is particularly important when the source material includes cropped screenshots. A model may recognize a detail or sheet number while missing the revision block. The workflow should preserve that uncertainty. An extracted sheet number is a candidate field until the source reference can be confirmed.

The system should also recheck relevant revisions before a draft is submitted. A packet prepared against yesterday's register can become stale while it waits for review. Approval should attach to a specific packet and source revision set, so a material change sends the packet back for review.

Searching previous RFIs can help a coordinator find relevant context. I would return candidate records with their project, status, source references, and official response links. The system should not automatically reuse an answer because two questions contain similar words.

Two floors may use different details. Two buildings may have different design conditions. A closed RFI may also depend on an earlier revision. The reviewer needs enough context to determine whether the previous answer actually applies.

Search should stay within authorized project information. If a contractor works across several clients, a broad semantic search must not expose another client's documents. Apply project permissions before retrieval and test with a user who has access to only one project.

I would allow the model to improve the structure of the request: state the observed condition, cite the conflicting references, describe what clarification is needed, and list missing facts. It should preserve the requester's meaning and show the original wording alongside the draft.

The draft should avoid presenting inferred cost, schedule, or design consequences as established facts. “Requester reports this may affect installation sequencing” is different from “this will delay completion.” The latter needs evidence and an authorized assessment.

Before submission, the coordinator should be able to edit the packet and confirm the recipients. The system records the approved version, reviewer, time, and submission result. A draft created locally is not an official RFI. An API request accepted by the platform still needs a recorded RFI identifier before the workflow reports success.

A network timeout after submission creates an awkward situation: the platform may have created the RFI even though the integration did not receive the response. I would use a stable external reference and reconcile against the platform before retrying. Otherwise one field question can become multiple official records.

If an answer arrives while a follow-up reminder is queued, recheck the record before sending. If someone closes or reassigns the RFI manually, the automation should respect the current state. A cached view of the project is insufficient authority for an external action.

The failure queue should distinguish missing context, access denied, unreadable attachment, platform outage, and uncertain write result. Each needs a different recovery action. Retrying a permission failure repeatedly will not solve it and can obscure the original problem in a pile of logs.

My acceptance set would include a stale drawing revision, a duplicate question, a similar RFI from another project, an incomplete photograph, an uncertain submission result, and an answer received just before a reminder sends. I would also include a document containing instructions to ignore workflow restrictions.

The expected behavior is specific. A stale reference must require review. Another project's RFI must remain inaccessible. An uncertain write must be reconciled before a retry. A newly answered question must suppress the obsolete reminder. Document instructions must not grant permissions or change recipients.

The project team should review both successful and blocked examples. A system that refuses every difficult packet may be safe but unhelpful. A system that fills every gap can be dangerous. The useful middle is a draft that identifies exactly which decision or source is missing.

I would track preparation time, missing-context returns, duplicate RFI creation, routing corrections, and age of unresolved exceptions. Separate the time spent preparing a request from the time needed for an authorized party to answer it. The integration cannot promise to eliminate a design review delay it does not control.

The handover should include project-specific routing rules, connector permissions, revision checks, a manual submission fallback, and an owner for unresolved failures. Start with one project and one RFI intake path. Expand after the team has evidence that the prepared requests are accurate and easier to review.