project_contacts
This table stores important people and organizations associated with a project, including internal contacts, external stakeholders, architects, inspectors, owners, and vendor-side points of contact.
Purpose
The purpose of this table is to maintain a project-level contact directory so users can quickly identify and route communications to the right people.
What this table does
- Stores named contacts associated with a project
- Supports both internal and external people
- Provides contact records for workflows, directories, and notifications
- Can be used to seed distribution groups and approval routing lists
Why this table is defined
DirtView needs more than just user accounts. Many project stakeholders may need to be referenced for communication, routing, or display even if they do not have active platform accounts.
Columns
| Column | Type | Required | Description | Example |
|---|---|---|---|---|
id |
uuid | Yes | Primary key for the contact record | pcontact_001 |
tenant_id |
uuid | Yes | Tenant that owns the project | tenant_001 |
project_id |
uuid | Yes | Project this contact belongs to | project_phoenix |
name |
text | Yes | Contact full name | Laura Chen |
company |
text | No | Organization or company name | Studio Axis Architects |
role |
text | No | Project role or business role | Architect |
email |
text | No | Primary email address | laura@studioaxis.com |
phone |
text | No | Primary phone number | +1-555-0202 |
is_external |
boolean | Yes | Whether the contact is external to the tenant organization | true |
metadata |
jsonb | Yes | Flexible contact metadata | {"discipline":"MEP"} |
Relationships
- tenant_id → tenants.id
- project_id → projects.id
- Contacts may be referenced by workflow routing, invite flows, or distribution logic at the application layer
How it is used
- Displayed in project contact directories
- Used when selecting workflow recipients or approvers
- Used to seed distribution groups
- Used for quick routing in RFIs, submittals, and other workflows
Access and security
- This table contains personal contact information and should be handled carefully
- Project visibility rules should apply
- Editing should be limited to authorized project users
- Changes to important routing contacts may need audit visibility
Example scenarios
Scenario 1: Architect contact
A project stores the primary architect contact even though they do not yet have a DirtView account.
Scenario 2: Inspector directory
Inspectors are added as project contacts for quick lookup and communication.
Scenario 3: Approval workflow setup
A PM chooses contacts from this directory when defining routing or approval chains.
Notes and assumptions
- This table is a directory, not an access-control table
- A project contact may or may not have an actual DirtView user account
- It is useful even before external guest onboarding occurs