Members & Roles
How members, roles, and permissions work in your app's organizations — the model behind multi-tenant access control.
Overview
When organizations are enabled, access in your app is governed by members, roles, and permissions. This page explains the model so you can reason about who can do what.
Members
A member represents a user's belonging to an organization — "user X is part of org Y." A single user can be a member of multiple organizations, with different roles in each. Membership also carries metadata like the join date.
Roles
Roles are named sets of permissions. SiteKnock ships with system roles and lets you define your own:
| Role | Typical capability |
|---|---|
| Owner | Full control of the organization |
| Admin | Manage members, settings, and most resources |
| Member | Standard access to the organization's features |
| Guest | Limited, read-mostly access |
A member can hold multiple roles in the same organization — their effective permissions are the union of all assigned roles.
Permissions
Permissions are granular capability codes (for example, org.create or admin.users.view). Roles grant permissions, and your backend checks permissions — not role names — when authorizing a request. This means access control stays accurate even as you customize roles.
Super admin
A user can be flagged as a super admin, granting full system access that bypasses per-organization permission checks. Reserve this for trusted operators of your platform.
Invitations
When invitations are enabled, organization admins can invite people by email. Accepting an invitation creates the membership and assigns the role specified in the invite.
Authorization is always enforced on the backend. The frontend may use roles for display hints (badges, menu visibility), but every protected action re-checks permissions server-side.