Sign in →

Organization

Manage the parent organization that groups your workspaces — org members and roles, invitations, self-service workspace provisioning, org-wide SSO, SCIM, and a consolidated billing rollup.

Updated 2026-07-29Suggest edits

Organization

Most Aforo work happens inside a single workspace — an isolated environment with its own products, pricing, customers, and usage data. The Organization console is the layer above that: it groups several workspaces under one parent company, so an org admin can manage people, access, and billing across all of them from one place instead of workspace-by-workspace.

Open it from Governance → Organization. The route is gated to workspace OWNER / ADMIN, but the page runs a second, authoritative check: you also need an organization role (ORG_OWNER or ORG_ADMIN). A workspace admin who isn't an org admin reaches the page and sees a "not authorized" state rather than the console.

Organization vs. workspace

These are two different objects, and the distinction drives everything on this page.

WorkspaceOrganization
What it isAn isolated environment — the unit that owns products, rate plans, customers, invoices, and usageA parent overlay that groups many workspaces
Holds business data?Yes — everything is scoped to itNo — identity, membership, and a billing rollup only
Who manages itWorkspace Owner / Admin (Workspace Admin panel)Org Owner / Org Admin (this console)
IsolationHard — no data crosses a workspace boundaryLogical — an org never merges its workspaces' data

An organization never pools data across its workspaces. It is a way to manage access and see consolidated billing, not a way to read one workspace's records from another.

The four tabs

The console is one page with four URL-addressable tabs (?tab=).

  • Workspaces — the org's identity and status (Active / Suspended / Archived), the list of workspaces it owns with your role in each, and the org lifecycle actions (Suspend, Archive, Restore). This is also where an org admin provisions a new workspace and detaches an existing one. Archiving the organization requires typing its name to confirm.
  • Members — the org-member roster with Add / Remove, plus a live "your role" card. Org membership is separate from workspace membership; this manages the former.
  • Billing — a read-only consolidated rollup: the parent total is the sum of each workspace's finalized invoices, broken down per currency and per workspace, with period presets (this month / last month / last 30 days). Setting up a payment method happens in the billing app, not here — this tab reports payer status only.
  • SSO — connect the organization's identity provider (OIDC or SAML) and map IdP groups to roles. See org-wide SSO below.

Organization roles and inheritance

An org role grants a matching workspace role in every workspace the organization owns. This is how you give someone access to a dozen workspaces at once without twelve separate invites.

Organization roleInherited role in every owned workspace
ORG_OWNEROwner
ORG_ADMINAdmin
ORG_BILLING_ADMINBilling Admin
ORG_SECURITY_ADMINViewer (SSO/SCIM surfaces are gated by the org role directly)
ORG_VIEWERViewer

Three rules govern how this resolves — they matter because they explain why someone can or can't see a workspace:

  • Only an Active organization grants inherited access. A Suspended or Archived org grants nothing — every inherited seat disappears until it's restored.
  • Effective role is the highest of the two paths. If you're an ORG_VIEWER but also a direct workspace ADMIN, you're an Admin there. Direct membership and inheritance don't fight — the stronger one wins.
  • Access is resolved from your identity, never from a header. The resolver keys on your signed-in user, so an X-Organization-Id sent by a client can't widen what you can reach.
ℹ

Per-workspace membership — inviting one person to one workspace with a specific role — lives in Workspace Admin → Members, not here. This console manages the organization-level roster and the roles that fan out across all workspaces.

Invitations

Both org-level and workspace-level invitations have a real lifecycle, not just a "sent" state:

  • An invite is keyed to an email address and binds to the account on first matching sign-in.
  • Invites can be resent or cancelled by an org admin.
  • Unaccepted invites expire — a scheduled sweep flips stale invitations to EXPIRED once their expiry passes. Expiry (EXPIRED) and an operator cancelling (REMOVED) are kept as distinct audit events so you can tell "they never accepted" from "we revoked it."

Self-service workspace provisioning

An org owner or org admin can create a new workspace directly from the Workspaces tab — no support ticket. Provisioning seeds a fresh, isolated workspace (with default billable units) and grants you a seat in it immediately. The button is disabled unless the organization is Active. Slug availability is checked platform-wide before creation, since a workspace slug is a shared public handle.

Org-wide SSO

Connect the organization's IdP once and apply it across every workspace. Configure it on the SSO tab:

  • OIDC or SAML. Secrets are never echoed back — the UI shows only whether a client secret / metadata document is set.
  • Map IdP groups to roles: either an org role applied across all workspaces, or a workspace role scoped to one workspace.
  • Removing the connection or editing group mappings requires a step-up MFA re-auth.

Org SSO takes precedence over per-workspace SSO. When the owning organization has SSO active, a workspace's own SSO tab renders a locked state that points back here — one identity source of truth, decided at the org.

SCIM provisioning

The organization exposes a full SCIM 2.0 endpoint so your IdP (Okta, Azure AD / Entra) can provision and deprovision users and groups automatically. IdP-facing requests authenticate with a SCIM bearer token (not an operator session), and you mint / rotate / revoke those tokens from the org console. The service advertises Users and Groups as read-write, PATCH and filtering supported, with a default 90-day token TTL. Full setup lives in SCIM Provisioning.

Endpoints

The console is wired to organization-service. The operator-facing routes:

GET/api/v1/auth/me/organizationsYour orgs + workspaces + roles
POST/api/v1/organizations/{id}/suspendOrg lifecycle (also /archive, /restore)
POST/api/v1/organizations/{id}/workspacesProvision a workspace (operator)
POST/api/v1/self-service/organizations/{orgId}/workspacesSelf-service workspace creation
GET/api/v1/organizations/{id}/membersOrg roster (also POST, DELETE)
GET/api/v1/org-statements/{orgId}Consolidated billing rollup
PUT/api/v1/organizations/{orgId}/ssoUpsert org IdP (secret encrypted at rest)
GET/api/v1/sso/precedenceDoes org SSO override workspace SSO?
POST/api/v1/organizations/{orgId}/scim/tokensMint a SCIM token (also rotate, revoke)

What this console does not do

  • It doesn't manage a single workspace's members — use Workspace Admin → Members for that.
  • It doesn't collect payment details. The Billing tab reports the payer's status and hands you off to the billing app to add a card; org-service never stores card data.
  • It doesn't hold business data. Products, customers, and invoices live in workspaces; the org only rolls up their finalized-invoice totals.