Roles and workspace access
Owners, admins, members, invites, and what they can influence.
Last updated: May 2026
Roles are layered
Fulreach today uses parallel concepts that share similar labels (Owner, Admin, Member) at:
- Application / organisation entitlement (
user_appsfor Fulreach)—who can onboard others, oversee billing-invite tooling, bypass certain scope checks in transitional implementations. - Workspace membership—who participates in outbound for a workspace and can mutate workspace resources.
Treat them independently until the product merges them into one mental model in UI release notes.
Application-layer summary (Fulreach tenant)
Designed intent (from internal role hierarchy spec):
| Role | Behaviour (target understanding) |
|---|---|
| Owner | Controls organisation onboarding / billing-invite tooling and can escalate other administrators. Invite-only platform flows historically required Fulreach Owner persona to orchestrate Stripe-linked invites |
| Admin | Helps manage workspaces and membership where implemented |
| Member | Receives workspaces explicitly added by elevated roles—does not roam across organisation silently |
Operational nuance today: Fulreach codebase still differentiates behaviours for temporary scope bypass semantics evolving under internal tickets—if something feels asymmetric between app admin vs member, escalate with support referencing both user_apps role vs workspace_members role.
Workspace-layer membership
Inside a workspace, roles influence whether you can reorganise outbound accounts versus using them narrowly (see rbac matrix historically for workspace admin moves). Typical member path: collaborate on sequences & campaigns constrained to memberships.
Invite management
Fulreach platform onboarding ties payment success to activating app rows—Owners initiate / revoke invites impacting downstream Supabase bookkeeping.
Always keep invite email ≡ sign-in identity parity to avoid orphaned pending payment states blocking activation retries.