super_admins
This table stores DirtView owner-org staff accounts that are authorized to operate the internal admin dashboard. These users are platform operators, not tenant users, and they exist outside tenant scope.
Purpose
The purpose of this table is to define the internal staff identities that can create tenants, manage tenant lifecycle, change feature flags, impersonate users, and perform other high-trust administrative actions across the platform.
What this table does
- Represents internal platform operators
- Separates super-admin identity from tenant user identity
- Supports onboarding, suspension, and platform-level operations
- Provides the actor identity for privileged admin audit logging
Why this table is defined
DirtView needs a hard separation between internal platform operators and customer-side users. Super-admins have cross-tenant power and must therefore be modeled separately from tenant-scoped memberships and RBAC.
Columns
| Column | Type | Required | Description | Example |
|---|---|---|---|---|
id | uuid | Yes | Primary key for the super-admin record | sadmin_001 |
email | text | Yes | Internal DirtView email address | ops@dirtview.com |
name | text | Yes | Display name of the super-admin | Alice Johnson |
is_active | boolean | Yes | Whether this admin can log in and act | true |
last_login_at | timestamptz | No | Last successful login | 2026-04-11 09:00:00+00 |
mfa_enabled | boolean | Yes | Whether MFA is enforced | true |
created_by | uuid | No | Existing super-admin who created this account | sadmin_000 |
created_at | timestamptz | Yes | Creation timestamp | 2026-03-30 08:00:00+00 |
Relationships
- id is referenced by admin_audit_log.super_admin_id
- id is referenced by feature_flags.set_by_super_admin_id
- id may be referenced by impersonation and feature-management tables
How it is used
- Authenticates into the internal admin application
- Creates and configures tenants during onboarding
- Suspends/unsuspends tenants and forces logout actions
- Manages feature flags and support/debug operations
- Acts as the principal actor for platform-level changes
Access and security
- This is one of the highest-trust identity tables in the system
- MFA should be mandatory
- Provisioning should happen only via restricted internal workflows
- All super-admin actions must be logged to admin_audit_log
- The service role key used by the admin backend must never be exposed to clients
Example scenarios
Scenario 1: Tenant onboarding
A DirtView operations user provisions a new tenant and initial branding.
Scenario 2: Feature rollout
A super-admin enables Drawings Beta for selected tenants using feature flags.
Scenario 3: Support intervention
A super-admin impersonates a tenant user to diagnose a production issue.
Notes and assumptions
- Super-admins are never tenant-scoped
- They should not appear in tenant membership or tenant RBAC tables
- Prefer a minimal, tightly controlled super-admin population