Organizations

The pieces that matter

Organization — your company account. People exist here. You define reusable review roles here (for example Security reviewer or SRE).
Workspace — one credential and policy boundary (an app, a production flow, or an agent). It is not a filesystem folder. Host-enforcer pairing and the Enforcer Gateway workspace Client ID both attach here.
Workspace roles — Owner, Maintainer, and Member on that workspace (who can edit policy and credentials). An organization Owner can create workspaces and has workspace Owner authority on every workspace in the org. An organization Maintainer does not.
Review roles — names you create on the org, then add to a workspace. Only then can you assign people and use them in that workspace’s approve/allow policy.

Who can approve: two kinds of assignment

Adding a review role to a workspace does not put everyone in the org on the hook. You still assign people:

This workspace only — a contractor who should see one flow, or a specialist on one service.
Whole organization — “this person is SRE everywhere we use the SRE role.” They count on every workspace that has that role added. They do not count on a workspace that never added it.

Typical setup: add Security reviewer to all production workspaces, assign your security staff once at org level, and they cover every new production workspace you attach that role to. No re-invite per workspace.

Click path in Platform.App

Create or open an organization. Invite people and assign org Owner / Maintainer / Member.
Define review roles on the org (name and key only — no members yet).
Create a workspace (organization Owner).
Add review roles to that workspace, then assign people (this workspace, and/or org-wide for a shared pool). Invite to the workspace as Owner, Maintainer, Member, or a review role.
Write a governance policy: named people and/or “at least N of this review role.”
On the workspace page, mint a workspace credential (Client ID + secret). The secret is shown once. Workspace Owner or Maintainer, or an organization Owner (not org Maintainer unless they are also workspace Owner/Maintainer). Rotate keeps the same Client ID and issues a new secret; revoke disables it.
Point Enforcer Gateway at the Integrations Gateway with that Client ID + secret. No PAT and no consent prompt.

What if we grow?

You do not need extra layers for “we have several apps” or “security reviews everything.” Use more workspaces and the two assignment kinds above. Here is how common situations map.

You need…	In Airlock
The same reviewers on every production workflow	Org-wide assignment + add that review role to each production workspace
Someone who should only approve one workflow	Assign them on that workspace only
Frontend vs backend vs a full-repo gate	Separate workspaces (they may overlap the same repo)
Several products, one security staff	One org, many workspaces, org-wide security role
A one-off list that is not a job title (this week’s on-call)	Named people on that policy, or a short-lived review role
Two product lines that must not see each other’s people, roles, or admins	Two organizations (or talk to us — that is more structure than one shared org)

Airlock does not use a Project or Team layer. If you later need a named group that is not a permission (for example a synced directory group), or a wall inside one company so one product’s admins cannot manage another’s people and role names, that is when we would add more structure. Until then, org + workspaces + review roles is the whole model.

Mobile (read-only)

In the Mobile Approver, Organization & policy lists your orgs, workspaces, and why you count toward a policy. That is not the same as pairing do-not-disturb policies.

Airlock Apps vs workspace keys