rfis
This table stores top-level Request for Information records. Each row represents one RFI and holds the current state, ownership, routing status, due dates, and key identifying metadata.
Purpose
The purpose of this table is to store the canonical RFI record that users search, view, track, and report on throughout the project lifecycle.
What this table does
- Stores the main business record for an RFI
- Tracks current status and ball-in-court ownership
- Links RFIs to projects and optionally to drawing locations
- Acts as the parent record for threaded responses and history
- Supports dashboards, filters, reporting, and notification workflows
Why this table is defined
DirtView treats RFIs as first-class workflow entities. Users need a stable object with searchable fields, due dates, routing state, and relationships to drawings, attachments, and threaded responses.
Columns
| Column | Type | Required | Description | Example |
|---|---|---|---|---|
id | uuid | Yes | Primary key for the RFI | rfi_001 |
tenant_id | uuid | Yes | Tenant owning the RFI | tenant_001 |
project_id | uuid | Yes | Project the RFI belongs to | project_phoenix |
rfi_number | text | Yes | Human-visible RFI number | RFI-042 |
subject | text | Yes | Short title or subject | Clarify stair landing detail |
question_text | text | Yes | Main question/request text | Please confirm the landing elevation... |
status | text | Yes | Workflow status | open |
current_party | text | No | Current responsible party / ball-in-court | architect |
created_by | uuid | No | User who created the RFI | user_123 |
assigned_to_contact_id | uuid | No | Current external/internal contact | pcontact_009 |
due_date | date | No | Requested due date | 2026-04-18 |
drawing_sheet_id | uuid | No | Optional linked drawing sheet | dsheet_001 |
drawing_pin | jsonb | No | Optional pinned location on drawing | {"x":0.42,"y":0.61} |
distribution_group_id | uuid | No | Default notification group | dgroup_010 |
metadata | jsonb | Yes | Flexible workflow metadata | {"cost_code":"03 30 00"} |
created_at | timestamptz | Yes | Creation timestamp | 2026-04-11 11:00:00+00 |
updated_at | timestamptz | Yes | Last update timestamp | 2026-04-11 12:10:00+00 |
closed_at | timestamptz | No | When the RFI was closed | NULL |
Relationships
- project_id → projects.id
- drawing_sheet_id → drawing_sheets.id
- distribution_group_id → distribution_groups.id
- id is referenced by rfi_threads.rfi_id
How it is used
- Used in RFI list screens and dashboards
- Queried for open/closed/overdue reporting
- Used as the primary object for routing and notification triggers
- Linked to drawings for location-aware issue tracking
Access and security
- Project membership and module permissions must apply
- External access should be constrained through guest access grants
- Status changes and reassignment should be audited
- Closed RFIs should remain read-only unless reopened by authorized users
Example scenarios
Scenario 1: Superintendent creates RFI from drawing
A user long-presses on a drawing location, opens an RFI form, and creates a new RFI linked to that sheet and pin.
Scenario 2: Architect response pending
The RFI remains open with current_party=architect until a formal response is posted.
Scenario 3: Closed RFI
After final response and distribution, the RFI status becomes closed.
Notes and assumptions
- Keep the main RFI table optimized for search and dashboard queries
- Detailed conversation history belongs in
rfi_threads - Use a separate numbering strategy per tenant or project as needed