profiles
This table stores the base application-level profile for an authenticated user. It is the platform identity record linked to the auth provider and is intentionally kept separate from tenant membership and employee records.
Purpose
The purpose of this table is to store reusable profile information about a user independently of any one tenant. This allows one authenticated person to potentially belong to multiple tenants while keeping one canonical profile.
What this table does
The profiles table acts as the root user profile layer.
- Stores name, email, phone, and avatar-like profile data
- Links directly to the auth user ID
- Supports one user belonging to multiple tenants through memberships
- Separates platform identity from business entities like employees
Why this table is defined
This table is defined to avoid duplicating basic user information across tenant-scoped tables. It also supports future cases where one person may need access to multiple tenants or multiple project contexts.
Columns
| Column | Type | Required | Description | Example |
|---|---|---|---|---|
user_id |
uuid | Yes | Primary key. Matches the auth provider user ID | user_123 |
email |
text | Yes | Primary email for the authenticated user | james@acme.com |
full_name |
text | No | User display name | James Walker |
phone |
text | No | Phone number for contact or notifications | +1-555-0101 |
avatar_file_id |
uuid | No | Optional reference to avatar/profile image | file_456 |
is_super_admin |
boolean | Yes | Convenience flag if platform wants to mirror elevated identity status | false |
metadata |
jsonb | Yes | Flexible profile metadata | {"locale":"en-US"} |
created_at |
timestamptz | Yes | Creation timestamp | 2026-04-01 08:00:00+00 |
updated_at |
timestamptz | Yes | Last update timestamp | 2026-04-11 09:15:00+00 |
Relationships
- user_id links to the auth provider user record
- user_id is referenced by tenant_memberships.user_id
- user_id may be referenced by employees.user_id when an employee has login access
- avatar_file_id may reference files.id
How it is used
- Loaded after authentication to display user identity
- Used as the base person record before resolving tenant context
- Referenced by membership and audit flows
- Used in UI for display name, avatar, and contact details
Access and security
- Users should generally be able to read and update their own profile only
- Tenant-scoped access should be enforced via
tenant_memberships, not by this table alone - Sensitive metadata should be controlled carefully
Example scenarios
Scenario 1: First login
A user authenticates and a base profile row is created or updated.
Scenario 2: Same user in multiple tenants
One person has one profile row, but multiple rows in
tenant_memberships.
Scenario 3: Employee + user link
An employee invited to the platform activates login access and the employee record is linked to this profile’s user ID.
Notes and assumptions
- This table is not a replacement for tenant memberships
- This table is not a replacement for employee business records
- Keep it relatively small and identity-focused