RFIs & Submittals

RFIs and submittals are structured, numbered, auditable review workflows layered directly over your project files. They're the coordination loop AEC teams run constantly - ask a formal question and get a formal answer (an RFI), or submit a document and get it stamped (a submittal) - but there's nothing construction-specific about the machinery. It's a review workflow with a paper trail, and it works for any team that needs "someone submitted this, someone decided on it, and here's the record of who and when."

The workflow is built by composing the pieces the rest of Swarmfile already provides: an RFI or submittal has a folder of attached files, so those attachments get previews, comment threads, version history, locking, and ACLs for free. What the workflow adds on top is state, assignment, due dates, numbering, and a decision of record.

Who can use them#

The RFIs tab in the web dashboard is visible to owners and admins. Access to an individual RFI's contents is governed by the ACL on the folder it lives under, the same as any other file - so a member granted access to that part of the project can see and act on it even though the top-level tab is admin-facing.

RFIs vs. submittals#

They share one engine but differ in intent and in the decisions available:

• An RFI asks a question. Its decision is an answer - or, if you need it, Approved / Rejected / Revise & Resubmit / a plain comment.
• A submittal puts a document up for review. Its decisions are the review stamps: Approved as Rev A, Approved as Rev B, Approved as Noted, Rejected as Noted, and Revise & Resubmit.

You pick the kind when you create the record.

Creating one#

Two entry points:

• From a folder - right-click a folder in the Files view and choose Create RFI from this folder. The new-RFI form opens with that folder as the attachment location already set.
• From the RFIs tab - create one directly and point it at a folder.

On the form you set the title and question (or submittal description), the kind (RFI or submittal), the reviewers it's assigned to, a due date, and a priority (low, normal, high, or urgent). You can attach files, which land in the record's own folder and behave like any other project files. Save it as a draft to keep working, or submit it to open it and notify the reviewers.

Lifecycle and ball-in-court#

An RFI moves through a defined set of states:

draft → open → in review → answered → closed. A record can be voided at any point.

Alongside the status, every RFI tracks ball-in-court - whose turn it is, the originator or the reviewer. Submitting a draft puts the ball with the reviewer; a decision hands it back to the originator; a request for revisions returns it to the reviewer again. Ball-in-court is what the due-date reminders key off, so the right person is nudged.

Making a decision#

A reviewer responds with a decision - an answer or a review stamp from the sets above - plus a message, and optionally a signature. The decision timeline is the record of account: it's a distinct, append-only history, separate from both the comment thread (informal discussion) and from file changes (which land as changesets). When you need to show what was decided, by whom, and when, that timeline is the answer, and it's what an audit looks at.

Requesting revisions sends the RFI back to in review with the ball returned to the reviewer; an answer moves it to answered; the originator accepting closes it.

Numbering#

Each project has its own RFI counter, and numbers are gap-tolerant: voiding an RFI leaves its number as a gap rather than renumbering everything after it. A scratch record you void doesn't burn a number out of the sequence, and no number is ever silently reused - the same convention tools like Procore follow, so the numbers you cite in correspondence stay stable.

Attachments, comments, and previews#

Because an RFI's attachments are ordinary project files under the hood, everything else in the product applies to them: thumbnails and inline preview in the detail view, comment threads with @-mentions, per-file version history, and locking. Marked-up PDFs, drawings, and photos attached to an RFI preview inline the same way they would anywhere else.

Notifications#

RFI activity generates notifications so nothing sits waiting on someone who doesn't know it's their turn:

• RFI created and assigned - to the reviewers it's routed to.
• Response posted and revisions requested - to whoever the ball moves to.
• Due soon and overdue - to the current ball-in-court, driven by a daily sweep.
• Closed and voided - to everyone involved.

There's also a ball-in-court digest for a periodic summary of what's waiting on you. These reach you through the in-app bell, tray toasts, and email (with the same per-kind preferences and quiet hours as everything else - see Notifications & Inbox).

External consultants#

The person who answers an RFI or reviews a submittal is often outside your org - a consulting engineer, an architect of record. Two paths, both fully audit-trailed:

• A "respond" share link - for first contact with no account. The consultant opens the link, sees the RFI read-only, and posts a decision directly. The decision is recorded against the share, so even an unauthenticated response has a trail.
• A full external collaborator - when the consultant is engaged properly, invite them as a guest (they get their own account). Their decisions carry their own identity, for a complete audit trail.

External consultants on RFIs count against your plan's external-collaborator allowance, the same as any other guest - see Sharing & Collaboration and Billing & Plans.

Finding them#

RFIs and submittals are full-text searchable by title and body from the dashboard omnibox, alongside files, projects, and people - see Search. A match jumps straight to the RFI.

On the desktop#

The RFI workflow itself is a web-dashboard surface - there's no RFI panel in the tray, because reviewing and deciding is coordination work, not work you do inside the mounted drive. What the tray does surface is RFI notifications as toasts, and a deep link that opens the RFI in your browser, so someone working in the tray still hears about an RFI waiting on them.

Where to go next#

• Sharing & Collaboration - comments, share links, and external collaborators, which RFIs build on.
• Notifications & Inbox - how the RFI alerts above are delivered and configured.
• Version Control - changesets, which is where an RFI's file changes (as opposed to its decisions) are recorded.