# Clerk orgs RBAC end to end

Roles and permissions only work as a chain: org enabled, role set defined,
roles created, permissions attached to features and roles, members assigned,
code checks. Break any link and authorization fails open or silently grants
nothing.

## The order

1. Enable organizations first (Configure, then Organizations in the dashboard).
   Role sets, roles, and permissions all hang off orgs. Defining roles before
   this leaves them unattached.
2. Open the Roles and Permissions page. Each organization gets a Role Set that
   decides which roles can be assigned to its members. Start from the default
   set before inventing custom ones.
3. Create custom roles only when admin and member are not enough. Limit: up to
   10 custom roles per instance. Each gets a name, a key (final form
   org:rolekey), a description, and a choice of whether it joins the default
   Role Set.
4. Create a Feature first, then custom permissions under it. Permission keys
   follow org:feature:permission. Permissions attach to roles, never directly
   to users.
5. Assign roles to members (Organizations, pick the org, Members tab, role
   dropdown) or through the backend API.
6. Enforce in code. On the client use has() for permission checks; on the
   server check auth() for org role or permission. A role nobody checks is
   decoration.

## The traps

- String-comparing the org role to "admin" breaks the day you add a custom
  role. Check permissions with has() instead of comparing role names.
- The default member role only carries read members and read billing system
  permissions. It cannot manage the org. If members need more, that is a new
  role or new permissions, not a tweak to member.
- System permissions like org:sys_memberships:manage power Clerk's own
  components. Do not assume a custom role with zero system permissions can
  drive the organization profile components.