An organization is the top of your Authdog account. It groups one or more tenants under shared billing, administration, and membership.
This is your account boundary. It isn't a directory of the customers who sign in to your app. Those people live in an environment's user store.
Platform hierarchy
Organization
└── Tenant (workspace)
└── Project (application / product)
└── Environment (dev · staging · production)- Organization. Billing, logo, owner, and the people who administer the account. It owns tenants through organization–tenant links.
- Tenant. The day-to-day workspace: projects, team access, domains, and settings. See Multi-tenancy.
- Project and environment. Where applications, keys, connections, and the end-user store live.
The CLI and the console follow the same path. Pick an organization when the account has one, then a tenant, a project, and an 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). They are not end users in an environment's user store. Removing a membership revokes console and API access for that organization. It doesn't delete the underlying user account.
Invite teammates by email, with a role. You can also attach tenant access to the invite, so the new member can enter 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 through 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 the console clears the lower scope (tenant, project, environment), so you don't act on the wrong subtree.
Organizations vs tenants
Use an organization when you want one billing and admin umbrella over several workspaces. Use separate tenants when products, clients, or business units shouldn't share projects, teams, or settings.
Don't create one organization per end-customer company, unless that company is its own Authdog account, with its own tenants and its own billing.
An environment can store customer records (an external key and a display name) for the app's own customers. Those records aren't organizations, and they don't add a second SSO connection. Enterprise SSO stays one connection for the environment.
Related
| Read | To learn how to |
|---|---|
| Multi-tenancy | Keep tenants, projects, and environments apart |
| Tenants | Create and select workspaces in the console |
| Projects | Add applications inside a tenant |
| Environments | Manage stages and credentials |