#How membership works

Every workspace in Olyron CRM is a tenant. Membership is stored one row per person per workspace in the tenant_users table, which links a Supabase auth user to a tenant, carries their role, and tracks a status. A person can belong to more than one workspace and switch between them.

When you first create your organization during onboarding, the atomic create_tenant_with_user database function inserts you into tenant_users with role org_owner and status active. That founding owner is the seat every other member is added from.

tenant_iduuid

The workspace this membership belongs to. Every row is scoped to one tenant.

user_iduuid

The Supabase auth user. A person only appears here after they have signed in to Olyron at least once so an account exists.

roleuser_role enum

One of org_owner, agency_admin, lead_manager, advisor, staff, or read_only. Defaults to advisor.

statususer_status enum

One of active, invited, or inactive. Only active members can sign in and act in the workspace.

joined_at / invited_at / invited_bytimestamptz / uuid

Audit timestamps and the user who added them. joined_at is set when a member becomes active.

#Roles and what they can do

Olyron CRM ships six roles. Two of them (org_owner and agency_admin) are administrators who can manage the team and organization settings; the rest are operational roles with progressively narrower access. Capabilities are defined in src/lib/rbac/capabilities.ts.

Capability highlights

• org_owner and agency_admin hold every CRM capability, including leads.assign, leads.override, reports.view_all, reports.export, and all settings.* (round_robin, business_hours, sla, targets, email_ab) plus sla.override.
• lead_manager holds the same operational set as admins for lead work (assign, override, all settings.*, sla.override, lead_manager.dashboard) but is not a team administrator.
• advisor can view and export only their own reports (reports.view_self, reports.export).
• staff and read_only are limited to reports.view_self.

#Adding and onboarding a member

Team Management lives at /dashboard/settings/team. The invite form and the member actions are only shown to administrators (org_owner or agency_admin); everyone else sees a read-only roster.

1. 1
   Have the teammate sign in first

   Membership attaches to a Supabase auth user, so the person needs an Olyron account. Send them to the sign-in page, where they can request a magic link (signInWithOtp) with their work email. Signing in once creates their profile.
2. 2
   Open Team Management

   As an org_owner or agency_admin, go to Settings, then Team (/dashboard/settings/team). You'll see the Invite Team Member form above the member roster.
3. 3
   Enter the email and choose a role

   Type the teammate's email and pick a role from the dropdown. Advisor, Staff, and Read Only are always available; Lead Manager appears for admins; Agency Admin is offered only to an org_owner.
4. 4
   Grant the role

   Submit the form to register the intended role for that person. An admin can then set or confirm the member's role from the roster (see the next section).

#Changing roles and removing members

From the member roster, administrators can change any teammate's role inline or deactivate them. Both actions write directly to the tenant_users row and take effect immediately.

Change a role

• Use the role dropdown next to a member to switch them between Advisor, Staff, and Read Only at any admin level.
• org_owner and agency_admin can additionally assign Lead Manager.
• Only an org_owner can assign Agency Admin or Org Owner.
• You cannot change your own role from this screen — the role control is hidden for the currently signed-in user to prevent self-lockout.

Remove a member

The Remove action does not delete the row; it sets the member's status to inactive. Inactive members are filtered out of the active roster and can no longer resolve tenant access, because membership resolution requires status = 'active'. To restore someone, set their status back to active in the database.

#Organization-level admin actions

Beyond the team roster, a few organization-wide actions are gated by role at the API layer. These are enforced server-side in /api/organization regardless of what the UI shows.

# Only the org_owner can do this, and the confirm token is mandatory.
curl -X DELETE "https://<your-workspace>/api/organization?confirm=DELETE" \
  -H "Cookie: <authenticated session>"

# Missing or wrong confirm value returns HTTP 400:
# { "error": "Deletion must be confirmed with ?confirm=DELETE" }

#Members in more than one workspace

Because membership is per-tenant, one person can belong to several workspaces — for example an agency admin who also advises inside a partner org. Olyron tracks the active workspace with the active_tenant_id cookie (or an x-tenant-id request header).

• When resolving which workspace a request runs in, Olyron honors the preferred tenant from the cookie or header if you are an active member there.
• If no preferred workspace is set, it falls back to your most recently joined active membership (highest joined_at).
• Your role is resolved per workspace, so the same person can be an org_owner in one tenant and an advisor in another.