# Organizations

Account UI provides a complete organization management interface when `VITE_ENABLE_ORGANIZATIONS=true`. Teams are a separate opt-in (`VITE_ENABLE_ORG_TEAMS`), surfaced when the compiler detects `organization({ teams: { enabled: true } })` in the Better Auth config.

## Organization CRUD

- Create new organizations, with `checkSlug` debounce on the slug field
- Update name, **slug** (rename navigates to the new URL), **metadata** (JSON object), and logo
- Delete organizations — gated on the `organization:delete` permission (default: owner)

## Member Management

- Invite members by email (with an optional team picker when teams are enabled)
- Assign roles: **owner**, **admin**, **member**
- Change roles and remove members — actions are filtered per-target by the role hierarchy (non-owners can't manage owner-role members)
- Leave the organization

> **Note:** These three roles (`owner`, `admin`, `member`) are Better Auth's built-in organization roles and map directly to Account UI's role picker. Use the same roles in your Quickback [Access](/compiler/definitions/access) rules — with [`auth.roleHierarchy`](/compiler/definitions/access#role-hierarchy) configured, you can write `roles: ["member+"]` to mean "member and above."

## Invitations

- Pending invitation list, per organization
- Resend, cancel (per-org), accept, and reject (per-user)
- Pending invites across organizations land on the user's `/dashboard`
- Invitations carry an optional `teamId` when teams are enabled — the invitee joins that team on accept

## Teams

Set `organization({ teams: { enabled: true } })` in your Better Auth config. The compiler emits `VITE_ENABLE_ORG_TEAMS=true` and the SPA exposes:

- **Teams tab** on each organization, split into "Your teams" and "Other teams"
- **Team detail** page with member roster, add/remove members
- **Active-team picker** in the organization header — switches `session.activeTeamId` via `setActiveTeam`, so server-side handlers can scope by team
- **Team-aware invitations** — when sending an invite, optionally pick a team; the member is added on accept

Per-team actions (create / rename / delete / add-member / remove-member) gate on the `team:create`, `team:update`, and `team:delete` permissions from Better Auth's default statements.

## Permission-aware UI

Account UI uses Better Auth's `checkRolePermission` API instead of hardcoded role checks. The `OrganizationContext` exposes a `can(resource, action)` helper that handles the default statements (`organization`, `member`, `invitation`, `team`, `ac`) and respects any custom roles you've registered via the BA `ac` option.

Multi-role users — Better Auth stores multiple roles as a comma-separated string — are handled by checking each role independently; the action is allowed if any one of them grants it.

This means projects that ship custom roles get a UI that matches what their server actually authorizes, without modifying the Account SPA.

## Related

- [Environment Variables](/stack/account-ui/environment-variables)
- [Account UI Overview](/stack/account-ui)
