Organisations, Users, And Teams

Organisations are the top-level tenant boundary. Users belong to an organisation, teams belong to an organisation, and most governed resources are scoped to an organisation.

Roles

Odock uses four platform roles:

Team membership also has a role:

User Status

Users can be:

The RBAC condition helpers also include active, pending, and inactive terminology. The active database enum is ACTIVE, PENDING, and REVOKED.

Organisations

An organisation has:

• name,
• contact,
• status,
• branding JSON,
• policies JSON,
• providers,
• provider keys,
• models,
• MCP servers,
• teams,
• users,
• API keys,
• budgets,
• quotas,
• usage records.

The policies JSON is important because organisation-level routing enablement lives at:

{
  "routing": {
    "enabled": true
  }
}

The same column may also hold governance policies depending on the UI path used to edit it.

Teams

Teams group users and can own:

• team members,
• team-scoped API keys,
• budgets,
• quotas,
• usage records,
• MCP servers.

Team policies can also hold rate-limit/IP policy JSON. When the gateway resolves rate-limit policy for a request, team scope is evaluated after organisation scope and before API key scope.

Invitations

Invitations support:

• joining an existing organisation,
• creating an organisation draft,
• pending, accepted, revoked, and expired status,
• token hash storage,
• invited-by and accepted-by tracking.

Invitation API routes exist under both global and organisation paths, with public acceptance and completion routes under /api/invitations.

Practical Setup Order

For a new organisation:

1. Create the organisation.
2. Create or approve the organisation admin user.
3. Create teams if the organisation needs team boundaries.
4. Add users and team memberships.
5. Configure providers and provider keys.
6. Configure models.
7. Create API keys for organisation, teams, or users.
8. Grant API keys access to models and MCP servers.
9. Add rate-limit policies, budgets, and quotas.
10. Validate traffic through the playground.
11. Monitor usage records and observability dashboards.

RBAC Behaviors To Remember

• SUPER_ADMIN can use /admin/* and can access organisation workspaces.
• Non-super admins cannot use /api/admin/*.
• Organisation routes require the path organisation to match the user's organisation.
• Managers need team context to create, update, or delete many team-owned resources.
• The server gateway does not use UI RBAC. Runtime client access is enforced by API keys, model/MCP grants, policies, budgets, quotas, and safety checks.