--- title: "How to Automate RFI Processing in Procore Using AI and n8n" url: https://ishchuk.eu/blog/automate-rfi-processing-procore-ai-n8n published: 2026-09-30T23:33:29.000Z updated: 2026-09-30T23:33:30.826Z tags: [construction, procore, n8n, ai-automation, rfi] --- You can automate roughly 70 percent of the administrative work around RFIs in Procore with two pieces: a Procore webhook that fires when an RFI is created, and an n8n workflow that classifies it, routes it, drafts a first-pass answer from your spec documents, and writes the draft back into Procore. The engineering decision, meaning the technical answer itself, stays with a human. Everything around it - the logging, the routing, the "who handles drainage on level 3" question, the chase-up emails - does not need a human, and in 2026 keeping humans there is just burning margin. The Navigant Construction Forum study, summarized by the Construction Management Association of America, reviewed 1,362 projects and about 1.1 million RFIs. The headline numbers: - Average of roughly 796 RFIs per project - About $1,080 to review and respond to each one - Around 8 hours of combined effort per RFI - Roughly $860K in total RFI review cost on an average project - 9.9 RFIs per $1 million of construction cost overall, but 17.2 per $1M on projects between $5M and $50M That study uses 2013 dollars, so read the figures as a floor. In 2026 I would treat them as understated. ## What an RFI actually costs you, and why the boring ones matter An RFI, Request for Information, is a formal question a contractor or subcontractor sends to the architect or engineer when the contract documents are unclear or contradictory. That is the whole definition. It creates a written record, and that record is what later becomes a change order claim or a schedule-extension argument. Here is the part most people miss: the expensive RFIs are not the hard technical ones. The hard ones need a senior engineer no matter what. It is the flood of repeatable ones that eats your week. "Which spec section governs the firestopping at the curtain wall?" has been answered on the last three jobs this firm did. "What is the latest revision of drawing A-501?" should take seconds, not an RFI at all. I built one of these RFI classifiers for a mid-size GC last spring. Before the automation, their two project engineers opened every single RFI manually to figure out who should answer it. 210 RFIs in the project's first quarter. After we let the model tag and route them, the engineers stopped opening maybe 65 percent of them entirely - the routing went straight to the right discipline lead with a priority flag. Nobody lost their job. They just stopped doing clerk work. ## How Procore's webhook and API make this possible Procore exposes the RFI object through its REST API and supports webhooks. In the Procore Developer Portal you create an application, add a webhook subscription on the RFI resource for the create event (Procore's webhook tooling names it as resource plus event type rather than a dotted string like rfi.create - follow the current naming in the portal), and point it at an n8n webhook URL. Every time someone creates an RFI on a project where your app is installed, Procore POSTs a JSON payload to your workflow instantly. No polling, no cron job hammering the API. Two practical notes from doing this: - Use the OAuth 2.0 Client Credentials flow for the server-side token. You POST your client_id and client_secret to Procore's token endpoint and get a bearer token back. Store it in n8n's credentials manager, not in the workflow JSON. - Scope the webhook to rfi.create only. Procore emits enormous webhook volume on active projects - change_order.update, daily_log.create, everything. If you subscribe to all events you will flood your n8n instance and your logs will be unreadable within a week. There is no native Procore node inside n8n, at least none worth using. You use the HTTP Request node against Procore's REST API for the read-back and write-back calls. That is honestly an advantage: when Procore changes field names, and they do, you fix one HTTP node, not a packaged integration you cannot see inside. ## The n8n workflow, step by step The architecture that has survived real projects for me looks like this. ### Step 1: Ingest and extract The webhook trigger receives the rfi.create payload. Pull out the RFI number, title, question body, originating subcontractor, and the project ID. The payload is small; you will need a second API call to fetch the full RFI body and attachments list. Cache the token. ### Step 2: Classify with an LLM Send the RFI text to a model - Claude, GPT, whatever your shop standardized on - with a prompt that asks for four things: discipline (electrical, structural, mechanical, drainage), priority (schedule-critical or routine, based on contract response deadlines), whether the answer likely exists in the project spec documents, and whether it smells like a disguised change-order claim. That last one matters more than people think. RFIs that reference "additional cost" or "inconsistent with the issued drawings" are frequently claim setup, and flagging them early protects you during negotiations. ### Step 3: Retrieve and draft For RFIs where the answer probably exists in your documents, run a retrieval step against your spec book and drawing set - this is the RAG part, retrieval-augmented generation, where the model answers only from documents you feed it. The output is a draft answer with citations to the spec section it came from. Always keep the citations in the draft. An answer without a source citation is worse than no answer, because it creates false confidence, and false confidence on a jobsite becomes rework. ### Step 4: Route and write back n8n routes on the classification. Make the routing concrete and construction-native: have the LLM read the referenced spec division out of the RFI text, then map it - Division 23 goes to mechanical, Division 26 to electrical, Division 31 to earthwork, and so on. High priority goes to that discipline lead via Slack DM with the RFI number and link. Routine ones land in a queue. For every RFI, the workflow writes the classification and draft back into Procore via the API, either as a private comment or into a custom field, so the project engineer sees the AI's prep work inside the tool they already live in. ### Step 5: The escalation cron A second scheduled workflow runs daily, pulls every open RFI past its response deadline, and escalates. This is the unglamorous 20 percent of the build that saves projects. An RFI sitting unanswered past the contract response window is how claims start. Navigant's data put typical response times at 6.4 to 10 days, and most contracts I have seen set the obligation between 7 and 10 working days. Nobody tracks that by hand across 12 projects. The machine does. ## What Procore's own AI does and does not solve Fair question, since Procore has been shipping AI hard. Procore Assist, the conversational AI assistant that grew out of earlier Procore AI work and got its biggest push of enhancements around Groundbreak 2025 (photo intelligence, multilingual support, mobile), does document search and answer drafting with source citations. Procore's own claim is that pattern-matching against historical project data cut RFI response time by 45 percent for customers using it, and that Assist saves teams 30 percent of document search time. Treat both as vendor benchmarks, not audits - but the direction is right and the mechanism is real. So why build anything? Because Procore's AI lives inside Procore. It does not see your Slack, your email threads where subcontractors actually ask half their questions, your historical RFI responses from the pre-Procore era, or your subcontractor database. A custom n8n layer connects the RFI process to the rest of your operation. If your firm's world is entirely inside Procore, start with Procore Assist and skip this article. It almost never is, in my experience. ## What is the ROI of automating RFI processing? Self-hosted n8n runs on a $10-20/month VPS. The LLM spend for a project doing a few hundred RFIs a year is trivial - classifying and drafting a few hundred RFIs costs tens of dollars with current API pricing, not hundreds. Someone on your side needs to own the workflow: a technical PM or an outside consultant, and a realistic build with testing is a 4-6 week engagement. On the return side, the research numbers in this niche claim 10-15 hours a week saved per project manager. Honestly, that figure deserves a caveat: it comes from industry consulting estimates, not the Navigant dataset, and your actual RFI volume per PM decides your actual savings. The more defensible way to size it is bottom-up - take your RFIs per month, estimate what fraction is routable boilerplate (my client's was around two-thirds), and multiply by whatever an hour of your engineer's time really costs. The general pattern for document-heavy AI automation in construction is a 3x-10x ROI inside 12 months, and I would apply that only after a quarter of measuring, not before. Track two numbers once it is live: average RFI response time before and after, and the percentage of RFIs the engineer can close without walking to a senior engineer's desk. If response time has not dropped by a third after 90 days, the routing logic needs work. ## Where people get this wrong Two failure modes I keep seeing. First, letting the model answer RFIs directly without the citation step. LLMs hallucinate most confidently exactly where the stakes are highest - dense spec books and stamped drawings are hard input, and a wrong RFI answer is a liability document with your firm's name on it. A human has to review and approve every draft before it becomes an official response; treat the AI output as internal prep, never as the response of record. Second, automating before fixing the process - if your firm has no discipline owners defined, the workflow has nothing to route to. Garbage routing logic makes an LLM faster at delivering RFIs to the wrong person. Start with classification and routing only. Add drafting a month later, once the routing has earned trust. The RFI process rewards small, boring increments, and 2026 is the year to stop paying $1,080 in administrative cost for questions a machine can at least pre-chew. If you want a second opinion on where AI fits your RFI and submittal process specifically, that is the kind of thing I do - ishchuk.eu/contact. ## FAQ ### How much does it cost to process a construction RFI? The Navigant Construction Forum study of 1,362 projects found that reviewing and responding to a single RFI costs an average of $1,080 in combined labor, and an average project generates roughly 796 RFIs, putting total RFI review cost near $860,000 per project. Those figures come from 2013 dollars, so the real cost today is likely higher. ### Can n8n integrate with the Procore API? Yes. n8n has no native Procore node, but its HTTP Request node works with Procore's REST API for reading and writing RFIs and other project data. Procore also supports webhooks, so an n8n webhook URL can receive a JSON payload the moment an RFI is created, using OAuth 2.0 client credentials for authentication. ### How do you automate RFI processing in Procore? Set up a Procore webhook that fires when an RFI is created, point it at an n8n workflow, and let the workflow classify each RFI by discipline and priority with an LLM, route it to the right discipline lead, optionally draft a first-pass answer from your spec documents using retrieval-augmented generation, and write the classification back into Procore via the API. A daily escalation job chases RFIs past their contractual response deadline. ### What is an RFI in construction? An RFI, or Request for Information, is a formal question a contractor or subcontractor sends to the architect or engineer when the contract documents are unclear or contradictory. It creates a written record that can later support a change order claim or a schedule-extension argument. ### Does Procore have built-in AI for RFIs? Yes. Procore Assist offers document search and answer drafting with source citations, and Procore claims customers using it cut RFI response time by 45 percent. However, Procore's AI only sees data inside Procore, so firms that also use Slack, email, or historical documents outside the platform often add a custom n8n automation layer. ### What happens if an RFI is not answered on time? Most construction contracts require an RFI response within 7 to 10 working days, and Navigant's research found typical response times of 6.4 to 10 days. An unanswered RFI past the contractual window can delay work, trigger claims, and weaken the responding party's position in change-order negotiations, which is why automated escalation workflows matter.