# 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](https://swarmfile.com/docs/guides/file-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 record tracks **ball-in-court** - whose turn it is, the originator or the reviewer. Submitting a draft puts the ball with the reviewer. **Revise & Resubmit** always leaves the ball with the reviewer, on both kinds - it's not a terminal decision, and a submittal specifically also bumps its revision (a → b → c, capping at c). What flips the ball back to the originator differs by kind: for an **RFI**, only the **answer** decision does - **Approved**, **Rejected**, and a plain **comment** all leave the ball with the reviewer. For a **submittal**, all four terminal review stamps do - **Approved as Rev A**, **Approved as Rev B**, **Approved as Noted**, and **Rejected as Noted** each hand the ball back to the originator and move the record to *answered*, since each one closes out the review; the originator's own `closed` action is the only step left after that. Ball-in-court is what the due-date reminders key off, so it's worth knowing which decision types move it. ## 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](https://swarmfile.com/docs/guides/version-control)). 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**: a record gets its number when it's created (drafts included), and voiding it leaves that number as a gap rather than renumbering everything after it. 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, Desktop App toasts, and email (with the same per-kind preferences and quiet hours as everything else - see [Notifications & Inbox](https://swarmfile.com/docs/guides/notifications)). ## 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, verifies their email once (no Swarmfile account is created), sees the RFI read-only, and posts a decision directly. The decision is recorded against the share with their verified email, so the response has a real trail even though there's no account behind it. - **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. An external consultant you invite as a guest counts against your plan's external-collaborator allowance, the same as any other guest; a respond-link consultant has no account and doesn't. See [Sharing & Collaboration](https://swarmfile.com/docs/guides/sharing-and-collaboration) and [Billing & Plans](https://swarmfile.com/docs/admin/billing-and-plans). ## Public project intake A public project opens a filing window (on by default, per project) so any registered Swarmfile user - a client, a consultant, a reviewer - can raise an RFI from the project's public page without joining the organization (turn it off under **Project settings** → **Public RFI intake**). The filing lands in an auto-created `RFIs/` folder at the project root with a priority the submitter picks; the team sees the submitter's verified name and email (recorded from their sign-in, never taken from their text), owners and admins get a dedicated notification and email, and the submitter gets an email when a member answers. Submitters track and reply to their filings under **My requests**, and members can filter the RFI list by public origin. Non-member attachments aren't accepted yet - a filing can describe the issue, and a member attaches files afterward. ## Finding them RFIs and submittals are full-text searchable by title and body from the dashboard omnibox, alongside files, projects, and people - see [Search](https://swarmfile.com/docs/guides/search). A match jumps straight to the RFI. ## Desktop App and CLI access ### From the Desktop App Reviewing and deciding is coordination work, not work you do inside the mounted drive, so there's no RFI panel in the Desktop App. What it does surface is **RFI notifications as toasts**, and a deep link that opens the RFI in your browser, so someone working in the Desktop App still hears about an RFI waiting on them. ### From the CLI Full command coverage - create, list, decide, and manage RFIs and submittals without leaving a terminal, the same workflow a build script or a headless render-farm node can drive: ```bash swarmfile rfi create ./Projects/tower-a/foundations --title "Slab thickness at grid C4" --body "Drawing S-201 shows 300mm, spec calls for 350mm - which governs?" --priority high --reviewer user_88 swarmfile rfi list --outstanding swarmfile rfi status rfi_9f2a swarmfile rfi decide rfi_9f2a answered -m "350mm per spec - drawing will be revised" ``` Unlike `mr`, RFI commands (other than `create`/`list`/`search`/`by-file`) take an RFI reference that you can give either way: the friendly display number (`RFI-003`, case-insensitive, resolved through the mounted project) or the internal `id` from `rfi create`/`rfi list`. `rfi status `'s exit code doubles as a CI gate the same way `mr status`'s does: `0` if `answered`/`closed`, `2` for every other state. See [the CLI reference](https://swarmfile.com/docs/cli/swarmfile) for the full command list. ## Where to go next - [Sharing & Collaboration](https://swarmfile.com/docs/guides/sharing-and-collaboration) - comments, share links, and external collaborators, which RFIs build on. - [Notifications & Inbox](https://swarmfile.com/docs/guides/notifications) - how the RFI alerts above are delivered and configured. - [Version Control](https://swarmfile.com/docs/guides/version-control) - changesets, which is where an RFI's *file changes* (as opposed to its decisions) are recorded.