Organisation settings and operational defaults
Manage identity, inherited review defaults, authentication availability, and access keys.
Organisation settings apply to the customer boundary in the URL. Owners and admins can change identity, defaults, team, billing, and access keys. Members and viewers receive role-appropriate read access only.
Use organisation defaults for policy shared across projects. Use project overrides when one product has a deliberately different review cadence.
The display name appears in the organisation switcher, headings, and lists. The slug is a lowercase alphanumeric-and-dash identifier used in console URLs.
Changing the slug redirects to the new organisation address. Update bookmarks and automation that stores human-facing console links.
Internal organisation IDs and /v1/organisations contracts do not change. Do not rename technical
identifiers solely to mirror customer-facing terminology.
Owners and admins can change identity. Reserved top-level console segments cannot be used as slugs.
Operational defaults govern review workflow, not runtime flag values.
The stale threshold controls when untouched flags are surfaced for review. New-flag defaults influence the starting configuration workflow for newly created resources.
Projects can override supported values. When a project override is absent, it inherits the current organisation setting.
| Change | Existing flags | New flags | Project override |
|---|---|---|---|
| Organisation review threshold | Recomputes future review signals | Applies | Explicit override wins |
| New-flag default | Does not rewrite configurations | Applies to future creation | Supported project value wins |
Changing a default does not rewrite existing environment fallbacks. Review inherited values before using an organisation-wide change to adjust team workflow.
Team settings contain invitations, accepted members, roles, removal, and owner transfer. Billing contains plan, cycle, trial or subscription state, invoices, receipts, and provider management.
Personal owners can begin promotion to a paid Team organisation from General settings. New team organisation creation starts through the organisation switcher and paid checkout.
Team organisations have an Authentication page showing plan availability for single sign-on and directory sync.
Provider configuration is not currently self-serve. Disabled controls are product status, not an instruction to configure an unavailable SSO or SCIM workflow.
Account passwordless email, optional OAuth, and passkeys remain account authentication mechanisms. They are managed separately from organisation roles.
Access keys manages preview Management automation credentials. Owners and admins create them with the narrow scopes required by automation.
Management keys are non-human control-plane credentials. They are separate from server runtime and browser client keys, which belong to project environments.
Raw management secrets are shown once. Store them in an automation secret manager and rotate them when ownership changes.
High-impact actions include ownership transfer, personal-to-team promotion, and organisation closure. Read the relevant lifecycle page and confirm billing and access consequences before proceeding.
Related pages: Management API overview, Roles and permissions, and Organisation closure.