distribution_group_members
This table stores the individual recipients that belong to a distribution group. Members may be internal tenant users or external email recipients.
Purpose
The purpose of this table is to define the actual recipient list behind a distribution group so the application can resolve who should receive a given communication or notification.
What this table does
- Connects recipients to a named distribution group
- Supports both internal and external recipients
- Allows workflows to send messages to reusable recipient sets
- Acts as the expandable recipient list during notification delivery
Why this table is defined
DirtView needs distribution groups to contain both platform users and non-user email recipients. That membership must be modeled separately from the group definition itself.
Columns
| Column | Type | Required | Description | Example |
|---|---|---|---|---|
id |
uuid | Yes | Primary key for the group membership record | dgm_001 |
group_id |
uuid | Yes | Distribution group this recipient belongs to | dgroup_001 |
membership_id |
uuid | No | Internal tenant membership if the recipient is a DirtView user | membership_123 |
external_email |
text | No | Email for an external recipient if not an internal user | architect@studioaxis.com |
external_name |
text | No | Optional display name for an external recipient | Laura Chen |
added_at |
timestamptz | Yes | When this recipient was added to the group | 2026-04-08 09:10:00+00 |
added_by |
uuid | No | User who added the member to the group | user_pm_001 |
Relationships
- group_id → distribution_groups.id
- membership_id → tenant_memberships.id when internal
- External recipients may correspond conceptually to project contacts, but do not have to
How it is used
- Expanded at send time by notification services
- Displayed in group management UI
- Used by workflows that send emails or alerts to groups
- Supports mixed groups of internal users and external emails
Access and security
- Group membership changes should be restricted to authorized users
- Email addresses should be validated carefully
- External recipients should be handled with caution for sensitive workflows
- Use constraints to avoid duplicate recipient rows where possible
Example scenarios
Scenario 1: Internal-only group
A group contains only tenant users, each referenced via
membership_id.
Scenario 2: Mixed group
A project RFI group includes internal PMs plus an external architect email.
Scenario 3: External-only recipients
A notification group is used purely for outside stakeholders who are not yet full platform users.
Notes and assumptions
- At least one of
membership_idorexternal_emailshould be present - This table models recipients, not workflow rules
- Membership should stay reusable across many workflow types