**Organizations** are the top of Authdog's resource hierarchy. An organization groups one or more [tenants](/docs/console/tenants) under shared billing, administration, and membership. It is *your* account boundary — not a per-environment customer directory inside an app.

## Platform hierarchy

```
Organization
└── Tenant (workspace)
    └── Project (application / product)
        └── Environment (dev · staging · production)
```

- **Organization**: billing, logo, owner, and the people who administer the account. Owns tenants through organization–tenant links.
- **Tenant**: day-to-day workspace — projects, team access, domains, and settings. See [Multi-tenancy](/docs/concepts/multi-tenancy).
- **Project / Environment**: where applications, keys, connections, and the end-user store live.

CLI and console scope follow the same path: pick an organization (when the account has one), then tenant, project, and environment. Accounts with no organization still work; navigation starts at the tenant list.

## Memberships and invitations

People join an organization through a **membership**. Members are account administrators (for example `admin` or `member`), not end users in an environment's user store. Removing a membership revokes console/API access scoped to that organization without deleting the underlying user account.

Bring teammates in with **invitations**: send an invite to an email address with a role. Optional tenant access on the invite can grant the new member entry to specific tenants when they accept.

## What an organization owns

| Concern | Scoped to the organization |
|---------|----------------------------|
| Billing and subscription | Plan and seat totals roll up across tenants |
| Tenants | Linked via organization–tenant associations |
| Service accounts and org keys | Automation credentials for management APIs |
| Member roles | Who can administer linked tenants and projects |

End-user identities, signing keys, and sign-in methods stay on the **environment**. Switching organization in the CLI or console clears lower scope (tenant, project, environment) so you never act on the wrong subtree.

## Organizations vs tenants

Use an **organization** when you need a shared billing and admin umbrella over multiple workspaces. Use separate **tenants** to isolate products, clients, or business units that should not share projects, teams, or settings. Do not create one organization per end-customer company unless that company is truly a separate Authdog account boundary with its own tenants and billing.

## Related

- [Multi-tenancy](/docs/concepts/multi-tenancy): how tenants, projects, and environments isolate config and users
- [Tenants](/docs/console/tenants): create and select workspaces in the console
- [Projects](/docs/console/projects): applications inside a tenant
- [Environments](/docs/console/environments): deployment stages and credentials