Skip to content

Organizations overview

An organisation is the top-level account in IntelliAuth — your company's account, the one created when someone at your company signs up. It's the boundary around everything you operate: the tenants you create for your business units / products / environments, the members who help you run the platform, the audit log, the plan, the billing relationship. One organisation per IntelliAuth customer; below it sit your tenants, and inside those tenants live your end-users.

When you sign up, the platform creates one row in its top-level catalog. From that row hangs:

  • Tenants — the isolated environments under your org. Each tenant is one of your business units, product lines, environments, or regions. Zero or more.
  • Members — the humans operating the organisation. At least one (you, the owner).
  • Plan — the contract describing what the organisation can do. Defaults to Free.
  • Audit log — chronological record of every state change in the org. Always present, never deleted.
  • Settings — name, slug, danger-zone delete.

Organisation doesn't directly own end-users (those live inside tenants); doesn't own applications (those also live inside tenants); doesn't own sessions, MFA enrollments, or branding configuration. Those are tenant-scoped concerns.

Two things move after signup:

  • Name. Editable from Settings. Renaming is instant — emails, invites, audit going forward show the new name. Past audit entries are not rewritten.
  • Plan. Through Billing (when it's wired for your plan). Upgrades take effect at the next billing cycle; rate limits and quotas are bumped immediately.

Three things are durable from signup:

  • Slug. Becomes the subdomain piece for tenant URLs (cymmetri<tenant>-cymmetri.intelliauth.local) and is referenced by every audit entry and every external integration that points at your platform. Your control plane itself lives at manage.intelliauth.local. If you need a different slug, the path is: create a new organisation, migrate your tenants, delete the old one.
  • Identity of the original owner. The owner role is durable on the human who signed the organisation up. Ownership transfer is a separate, deliberate flow.
  • Created-at timestamp. Just for the record.

Most teams have one organisation — your company gets one org, and the separation you need between business units / products / environments comes from tenants inside that org. Multiple organisations make sense only when:

  • You're a parent entity operating fully independent businesses (each with its own billing relationship, audit trail, identity team). Two organisations cleanly separates them.
  • A regulator demands organisation-level segregation, not just tenant-level. Rare but real for some financial / public-sector contexts.
  • You're a reseller / agency running IntelliAuth on behalf of clients who need owner-level control of their own environment.

For most companies, one organisation + one-tenant-per-sub-unit is the right pattern. Multiple organisations cost you operational duplication (separate billing, separate member lists) for the privilege of cleaner separation — only worth it when the separation is genuinely needed at the billing / audit level.

  • Settings — rename your org, see your slug, learn what the danger-zone delete does.
  • Delete an organisation — what happens when you remove an org, and when it's the right move.