Fluxo is designed for teams and agencies. In practice that means one person might be working across multiple client workspaces, and a client might need to approve content without seeing the automation machinery behind it.
So the multi-tenant model cannot be an afterthought. The boundary between tenants must be explicit, enforced server-side, and consistent across UI, APIs, background jobs, and billing.
Organization model
In Fluxo, the organization is the primary boundary. An organization owns the assets that matter:
- creator (billing owner anchor)
- members with role
- workflows, credentials, review resources
- optional white-label settings and installations
Each user stores an activeOrganizationId. Every server procedure resolves the active organization context before running business logic. That design is boring, but it is how you avoid cross-tenant bugs: the org boundary becomes part of every code path by default.
Role hierarchy and behavior
Fluxo uses a small number of roles with clear intent. I avoided a huge matrix of roles because role explosion becomes impossible to reason about and harder to secure.
The roles are:
- OWNER
- ADMIN
- PARTICIPANT
- REVIEWER
REVIEWER is the most important role conceptually. It is intentionally constrained to inbox-style operations only. Reviewers can approve, reject, and request revisions, but they cannot create workflows, manage credentials, or access settings. This is critical for agencies who want clients inside the governance loop without granting platform access.
I enforce reviewer restrictions at multiple layers: procedure guards and business-logic checks. That way it stays secure even if a UI bug exposes a hidden button.
Fine-grained selected access modes
Roles alone are not enough for least-privilege. Agencies frequently need “this person can edit these two workflows, nothing else”.
So Fluxo supports selected access modes per asset type:
- workflows
- credentials
When a mode is selected, explicit permission rows control view/edit rights. This gives least-privilege without inventing role variants like "participant-but-only-for-certain-assets".
Invitation lifecycle
Invitations are treated as state, not as “send an email and hope”. Each invitation includes role, token, expiry, and status transitions:
- PENDING
- ACCEPTED
- DECLINED
- EXPIRED
Fluxo enforces constraints like "an admin cannot invite an owner" and validates recipient identity at accept time. This prevents subtle privilege escalation paths.
Access checks in practice
For workflow and credential operations, Fluxo checks:
- org membership exists
- reviewer restrictions
- owner/admin bypass where appropriate
- selected-mode permission records for participant actions
These checks run server-side because cross-tenant safety cannot rely on client behavior. If someone can access the endpoint, the endpoint must enforce the rule.
Why this architecture scales
This structure scales because multiple platform concerns agree on the same boundary. Once the org boundary is consistent, you can layer features on top without constantly patching security assumptions:
- agency linking across client organizations
- per-org notification installations
- white-label branding and custom domains
- API keys scoped to organization
- embed tokens scoped to workflow or queue
This is how Fluxo can evolve from single-user automation into agency-grade multi-workspace operations without rewriting auth boundaries later.