Organizations and members

This page is for the person who runs an organization on compliance.tf: usually the platform or cloud admin who brings teams onto one plan and one registry host. By the end you will know what your organization owns, what its alias does to a module source, and how to invite people into it.

How it works

What an organization owns

An organization is the tenancy boundary. Everything the platform holds hangs off exactly one of them: the projects that group workloads, the configs that author a compliance posture, the snapshots those configs publish, the bindings that point an environment at a snapshot, and the registry tokens that let Terraform or OpenTofu fetch modules.

It is also the unit of entitlement. A plan is held by the organization, not by each person in it. When your access to the registry comes from an organization, every member draws on that one organization's allowance — headcount does not multiply it.

You can belong to more than one organization at a time, with a different role in each.

Personal and team organizations

The personal organization is created the first time you sign in, and creating it is idempotent — signing in repeatedly does not produce a second one. It exists so that a single user has somewhere to author configs and hold tokens without any team setup at all.

A team organization is what you want for shared work: several people, one plan, one alias, one audit trail.

Team organizations are created by compliance.tf, not in the product: an administrative command names the organization, assigns its alias, and installs the first owner in a single step. Ask for one during onboarding.

The alias, and the URL it creates

An alias is a DNS label, and assigning one to an organization brings up a registry host for it. That host is not a cosmetic vanity domain — it changes how a module source is read.

On a framework subdomain, the three path segments after the host mean what they mean on any Terraform registry — namespace, module name, provider:

source = "soc2.compliance.tf/terraform-aws-modules/s3-bucket/aws"

On an organization's alias host, the same three segments are read as project, environment, module:

source = "bobthecorp.compliance.tf/payments/prod/s3bucket"

The environment segment is what tells the two apart. It must be dev, staging, or prod — the three environments every project has. A source on an alias host therefore names a specific project environment, and what it resolves to is whatever snapshot that environment is currently bound to. That is the point of the alias: your Terraform code stops naming a compliance framework and starts naming your own project and environment, and the binding decides the posture.

Membership is enforced on every request to an alias host. A caller with no active membership in the addressed organization is refused outright rather than quietly served at their own personal tier, and removing someone takes effect within seconds rather than at the end of their session.

Roles

Every member holds one of three roles, member, admin or owner, and the separately granted approver capability decides who may approve and promote. The owner is fixed when the organization is created; an invitation can grant only admin or member. Treat admin as a full-trust grant: an admin can change roles and remove people, including the owner. Access control owns the definitions and the permission table.

Working in more than one organization

Accepting an invitation does not replace your personal organization. You belong to both, and you switch which one you are acting in. The switch is scoped to your session, and it re-checks your membership at the moment you make it — so a session cannot be pointed at an organization you do not belong to, whatever it was pointed at before.

Your role is per organization. Being an owner of your personal organization says nothing about your standing in a team you were invited into.

Where it is in the console

• The organization switcher changes which organization your session acts in. It re-checks your membership when you switch.
• The member list (roster) shows active members to everyone in the organization, and pending invitations to admins and owners. Invitations, role changes, the approver capability and removals are made from it.
• The organization's tokens screen holds its registry tokens; see Registry tokens.

Invite someone

The lifecycle, in order:

1. An admin invites an email address and picks the role, admin or member. This requires a trial, paid or enterprise plan; a free organization cannot invite.
2. Compliance.tf records a pending invitation and emails a link. The invitation is good for a fixed window, and the email states it.
3. The invited person opens the link. They can see who invited them and what role they are being offered without having an account yet — the link itself is what authorizes that preview.
4. They accept. This requires signing in with the exact address the invitation was sent to, and that address must be verified. An invitation sent to one address cannot be accepted by an account using another.
5. The role comes from the stored invitation. Nothing in the accepting request can influence it.

Declining works straight from the email and needs no account, which matters for the case that motivates it: an invitation sent to the wrong person.

Three operational facts worth knowing while an invitation is outstanding:

• Re-inviting the same address replaces the link. The previous link stops working immediately.
• A repeat invitation inside a brief cooldown is a no-op. Nothing is re-sent and the existing link stays valid, so a double-click does not invalidate the link already in someone's inbox.
• An admin can revoke a pending invitation at any time, and revoking one that is already gone is harmless.

What it does not do

• No self-service organization creation, and no alias assignment in the product: both are operator-run.
• No alias change. An alias cannot be renamed, released or reassigned once assigned.
• No conversion of a personal organization into a team organization, and no delete of an organization.
• No ownership transfer. The owner role cannot be granted after creation; see Access control.
• No seat cap. Seat figures are reported, not enforced; see Plans and entitlements.

Who may do what

• Any member can read the organization, its active-member list, and switch to it.
• Admins and owners rename the organization (the display name only; the alias never changes), invite people, revoke invitations, change roles and the approver capability, and remove members. Inviting needs a trial, paid or enterprise plan.
• Previewing or declining an invitation needs no account; the link is the credential. Accepting needs a signed-in, verified address that matches the invitation.
• Creating an organization or assigning an alias is not available in the product.

The full role and permission table is on Access control.

What gets recorded

Membership, role, approver-capability and invitation changes are not recorded in the audit trail. The member list shows the current state only.

Operating details

The rest of this page is the operator's half: every state an invitation can end in and the status it returns, how the last-admin guard behaves under concurrency, why invitation responses are deliberately uninformative, and the rules an alias must satisfy.

Related

• Projects and environments — what sits inside an organization, and the three environments an alias host addresses
• Access control — the permission model in full, including tenant isolation
• Registry tokens — personal and organization-owned tokens, and wiring them into Terraform
• Plans and entitlements — tiers, trials, and what gates on plan