If your firm runs Microsoft 365, you probably already pay for SharePoint (confirm your plan includes it). Building an RFI tracker on it costs no new licence fees, involves no procurement cycle, and keeps the data inside infrastructure IT already governs. For a firm handling a modest RFI load, that is a defensible v1. Firms we've spoken with often describe the do-it-yourself route as the low-friction option precisely because it adds no new tool for the team to learn.
The counterpoint is that SharePoint is a document and list platform, not a construction administration workflow engine. It has no native concept of ball-in-court, no link between an RFI record and the email thread that carries the substance, and no cross-project view of open items. Those gaps cost little at ten RFIs a month on one project. They compound at a hundred across five.
This article covers both halves: the SharePoint structure that works, and the specific points where dedicated software earns its cost.
Can you build an RFI system in SharePoint?
Yes. A SharePoint list with the right columns, two or three views, and a Power Automate reminder flow covers RFI logging, assignment, due-date tracking, and basic reporting. It is a workable system for a single project team with a moderate RFI volume, and it uses licences the firm already owns. Without significant custom development it cannot enforce workflow states, capture the related email automatically, or search across projects.
What a working SharePoint RFI tracker looks like
The list schema
Create one list per project (one list for all projects looks convenient but complicates permissions and reporting later). Columns that firms we've spoken with converge on:
| Column | Type | Notes |
|---|---|---|
| RFI Number | Single line of text | Manual, or auto-append the list ID. Decide the numbering convention before item 1. |
| Title / Question | Multiple lines | The question as asked, verbatim from the contractor. |
| Status | Choice | Draft / Submitted / In Review / Answered / Closed / Void. Keep it to six states or fewer. |
| Ball-in-court | Person | Who owes the next action. This column is the whole game. |
| Date Received | Date | |
| Date Due | Date | Drive reminders off this column. |
| Date Answered | Date | Lets you compute response time later. |
| Discipline | Choice | Arch / Struct / MEP / Civil / Other. |
| Spec Section / Drawing Ref | Single line of text | |
| Cost Impact / Schedule Impact | Yes-No | Two columns. Flags for the PM's weekly review. |
| Response | Multiple lines | The answer of record. Attach the marked-up sketch to the item. |
Views and permissions
Three views cover most needs: Open by ball-in-court (grouped on the person column, filtered to Status ≠ Closed), Overdue (Date Due ≤ today, not Answered), and All items for the record. Keep each view's filters tight. SharePoint's list view threshold blocks views that try to process more than about 5,000 items at once (Microsoft documentation), which a multi-year archive list can reach.
On permissions, resist item-level custom permissions. Give the project team edit rights on the list, give external parties (contractor, owner's rep) a separate submission path if they need one, and leave inheritance alone. Microsoft's own guidance recommends staying under 5,000 unique permission scopes per list, and permission inheritance cannot be broken at all on lists past 100,000 items (SharePoint limits). Complex permission schemes are where DIY trackers quietly rot.
Reminders
Power Automate ships a "Set a reminder" flow for any list with a date column, and a scheduled flow can email the ball-in-court person when Date Due is within N days (Microsoft documentation). Budget a few hours to build and test it. Assign an owner, because flows silently break when the list schema changes or the flow author leaves the firm.
Built this way, the tracker is serviceable. If your firm runs one or two projects at a time and the CA phase is light, you may not need to go further. Read the failure points below anyway, if only to know what to watch for.
Where the SharePoint approach breaks down
Five failure points recur in practitioner discussions and in conversations with firms we've spoken with. Each one is a workflow SharePoint was not built for.
1. No RFI state machine. A Status choice column records state. It does not enforce it. Nothing prevents an RFI from sitting in "In Review" for three weeks with nobody assigned, and nothing escalates it. Ball-in-court discipline depends entirely on the PM policing the list. Nothing in the tooling resists that drift; only the PM's attention does.
2. Email stays unfiled next to the list. The substance of most RFIs lives in email: the contractor's clarification, the structural engineer's markup, the "actually, ignore sheet A-301" correction. The SharePoint list holds a summary while the record of what was said sits in individual Outlook mailboxes. Firms we've spoken with describe PMs drowning in manual Outlook filing, and describe filing compliance running far below what the firm assumed. When a dispute surfaces two years later, the list entry is not the record you need.
3. No cross-project view. Each project's list is an island. "Show me every open RFI across the studio where we hold the ball" requires either merging lists (against the one-list-per-project design) or building a Power BI layer on top, which is a second system to maintain.
4. Version drift on the referenced documents. The RFI answer says "see revised detail 5/A-501," and which A-501 the contractor opens depends on library hygiene and sync behaviour. A superseded PDF that keeps circulating is how a team ends up pricing from the wrong bid set. SharePoint's version history is strong for a single file. It does not manage which revision is contractually current across a drawing set.
5. The audit trail is assembled, not produced. SharePoint logs item edits, but reconstructing "who knew what, when" for a claim means stitching list history, email threads, and file versions by hand. Dedicated tools log the full transaction (question, routing, response, attachments, timestamps) as one record because that is the artifact they exist to produce.
None of these five bites in the first month. They surface with volume and with disputes. That timing is the case for the DIY route as a v1, and the case against it as the permanent system.
SharePoint vs dedicated RFI software
| Criterion | SharePoint DIY | Dedicated RFI / PIM software |
|---|---|---|
| Licence cost | Covered by existing Microsoft 365 (confirm your plan includes SharePoint) | New line item. Pricing is typically quote-based and seat- or project-based. Confirm against your own quote. |
| Setup effort | Hours to days per project, in-house | Vendor onboarding, typically days to weeks. Ask vendors for a realistic timeline. |
| State tracking (ball-in-court, due dates) | Manual columns, no enforcement | Native workflow with assignment and escalation |
| Email capture | Manual filing by each PM | Automatic or one-click filing to the project record (this is Cogram's core claim for its own product) |
| Cross-project search | No, without a BI layer | Native |
| Version / current-set control | Library versioning only | Varies by tool. Test explicitly in a pilot. |
| Audit trail for disputes | Assembled by hand from lists, mail, files | Produced as a by-product of the workflow |
| Maintenance owner | Your firm (schema, flows, permissions) | The vendor |
If email capture or audit trail is the workflow that matters most to your firm, test that workflow explicitly in any pilot rather than taking a table like this one, ours included, at face value.
When to switch: five signals
- You run RFIs on more than two or three concurrent projects and nobody can answer "what's open across all of them" without opening each list.
- RFI volume makes manual filing unreliable. If PMs are visibly behind on filing the correspondence that carries the substance, the record is already incomplete.
- Dispute exposure is rising. Public-bid, institutional, or claims-prone work raises the value of a producible audit trail. Firms we've spoken with doing public-bid civic work describe a heavy, formal load of RFIs, submittals, and agency correspondence landing on a small team.
- You are the CA-phase architect or engineer, not the GC. GC-oriented platforms assume you are running the whole job. Design-side firms often need the information management layer without the construction-operations bundle.
- Staff turnover has orphaned the tracker. When the person who built the flows and views leaves, the DIY system stops evolving. If nobody owns it, it is already failing quietly.
One or two of these signals is a reason to tighten the SharePoint setup. Three or more is a reason to run a pilot of a dedicated tool on one live project and compare the record each system produces.
FAQ
Is SharePoint good for RFI tracking?
SharePoint is adequate for RFI tracking on single projects with moderate volume. A list with status, ball-in-court, and due-date columns plus a Power Automate reminder flow covers logging and follow-up at no extra licence cost. It lacks workflow enforcement, automatic email capture, and cross-project search, which matter as volume and dispute exposure grow.
Can you build an RFI tracker in SharePoint without coding?
Yes. A standard SharePoint list with choice, person, and date columns needs no code, and Power Automate's built-in "Set a reminder" flow handles due-date alerts without custom development. Expect a few hours of setup per project and assign a named owner, because flows and views need maintenance when schemas or staff change.
How do construction and design firms track RFIs?
Common approaches, roughly in order of formality, are: email plus a spreadsheet, a SharePoint or Microsoft Lists tracker, the GC's platform (such as Procore or Autodesk Construction Cloud, where the design firm works in someone else's system), and dedicated project information management tools that hold the firm's own record. Firms we've spoken with often combine two of these, which is itself a source of gaps.
What does dedicated RFI software cost?
Most vendors in this category quote rather than publish prices, and pricing models are commonly seat-based or project-based, sometimes bundled with a wider platform. Mid-size firms commonly report five-figure annual costs for bundled platforms. Treat any figure, including ones in articles like this, as a starting point and confirm against your own quote and contract.
Does SharePoint have RFI limits?
Not on volume in practice. A SharePoint list supports up to 30 million items (Microsoft), far beyond any firm's RFI count. The practical limits are operational: views that process more than about 5,000 items are blocked, and permission inheritance cannot be broken on lists past 100,000 items. Design the views and permissions accordingly.
Related reading
- RFI — what an RFI is and who owes what at each step
- Submittal — the companion workflow, same failure points
- The OAC meeting — CA-phase context, where RFIs get discussed and lost
- RFI and submittal management in Cogram — how Cogram handles RFI and submittal tracking
If you are weighing a move, the useful next step is a mapping of your current RFI record (where the list lives, where the email lives, who owns the flows) against the failure points above. We are happy to do that walkthrough with you, whatever you decide to run it on.