Organization
Your organization is the unit that holds everything else: the members, the roles, the data, the audit log, the storage, the keys. Most settings in the product are scoped to one organization.
The handful of settings that describe the organization itself live under Settings → Organization.
Settings you can change
- Name. The display name shown in the top bar, in emails, and across the product. Change it freely — there is no downstream impact.
- Slug. The short identifier used in URLs. In Cloud this is fixed at signup (see Access URLs). In Sovereign it can be edited by an install admin if you’re restructuring.
- Timezone. Default timezone for dates and times rendered in the workspace. Individual users can still override their own.
- Locale. Default language and date/number formatting. Individual users can override their own.
Saving any change to organization settings records an audit entry naming who changed what (see Audit Log).
Organization lifecycle
Every organization is in one of these states:
| State | What it means |
|---|---|
| Provisioning | The organization is being created. Users cannot sign in yet. This state is normally only visible for a few minutes during signup or on-prem org creation. |
| Active | Normal operation. Members can sign in, work, and use the product. |
| Suspended | The organization is paused. Members cannot sign in. Data is preserved exactly as-is. Used for billing holds (Cloud) or governance holds (Sovereign). |
There is no destructive “delete” workflow inside the product. Permanent organization deletion is an operator-level activity outside the workspace UI, intentionally.
Cloud vs Sovereign differences
| Cloud | Sovereign | |
|---|---|---|
| Who creates the organization | You, at signup | An install admin, through the protected organization setup wizard |
| Slug editable later | No (v1) | Yes, by an install admin |
| Suspension | By Novantra for billing/policy | By an install admin |
| Data isolation | Per-org schema in the shared platform DB | Per-org dedicated tenant database |
In Sovereign, organization creation is gated by an entitlement signed by the Novantra control plane. The install admin runs a protected wizard that confirms commercial approval, then provisions the org’s tenant database, keyring, and initial admin. You cannot create a Sovereign org without a valid license that names it.
Multiple organizations per install (Sovereign)
A single Sovereign install can host multiple organizations. Each gets its own:
- Tenant database.
- Encryption keyring (rooted in the install key provider, or in the organization’s own KMS if Self Managed Secret Keys is enabled).
- Members, roles, audit log, classification levels.
- Access URLs.
Organizations on the same install do not share data with each other. They share only the install-level infrastructure: the host machine, the mailer, and the install admins who manage them.
What’s not editable from the workspace
A short list of things that are deliberately not editable from inside the workspace settings:
- The organization slug in Cloud. Locked at signup; talk to your account team.
- The encryption keyring root. Configured at install (Sovereign) or signup (Cloud); changing it is a separate, governed migration. If you’re enabling Self Managed Secret Keys, see that guide.
- Active storage binding. Managed through Self Managed Storage settings, not general org settings.
- License and entitlements. Cloud reads these from the control plane automatically; Sovereign reads them from the signed license you applied at install.