Members and IAM
Who can do what — per-product roles, the Members pages, email invitations, and custom policies.
Access inside an organization is controlled by IAM policies attached to each member. You'll mostly interact with it through two surfaces: each product's Members page (simple role-based management) and the org-wide IAM section (invitations and custom policies). Every check is evaluated centrally — default-deny, explicit deny wins.
The roles
| Role | Scope | What it grants |
|---|---|---|
Owner (org:owner) | Whole organization | Full access to every product and to billing/IAM itself. The creator of an org gets this automatically. |
| Admin (per product) | One product | "Full access to [Service] — create, edit, and delete every resource." |
| Viewer (per product) | One product | "Read-only access. Can browse but not change or delete anything." |
| Translator (LangSync only) | LangSync, scoped | Can view everything, but edit translations only in the languages you pick — and optionally only in selected namespaces. |
Roles are per product, so one person can be Backup admin and DomainRadar viewer at the same time. Beyond the built-ins, you can create custom policies (below) for anything finer.
The Members page (per product)
Every product's sidebar has Members — e.g. "DomainRadar members": "Who has access to [Service] and what they can do." It shows:
- the member list (searchable), each with their role in this product shown as a dropdown — "Owner" grants full access across every service is noted right on the page;
- pending invitations you've sent, with status and expiry, and a revoke action;
- the Invite to [Service] button.
Two removal actions with different blast radius:
- Detach a role — "Remove [name] from [Role]?" — takes away one product role; the member keeps their other access.
- Remove from org — the dialog is explicit: "This pulls them out of every service — LangSync, SnapDB, Billing, DomainRadar, PromptHub — not just this one. Their account stays intact… Re-invite to grant access again."
Invitations
Invitations are by email, and the invitee doesn't need an account yet — they can sign up first and then accept.
From a product's Members page — "Invite teammate to [Service]": enter the email, pick Viewer / Admin (or Translator on LangSync, where you then choose the editable languages and optionally restrict to selected namespaces). On accept, they join the organization with exactly that role.
From IAM → Invitations (the org-wide view): the same mechanism, but you attach any set of policies — including custom ones — instead of a single role. This page also lists every invitation with its status (Pending / Accepted / Declined / Revoked / Expired) and lets you revoke pending ones.
How the mechanics behave:
- The invitee gets an email with a one-click accept link. After sending, the dialog also shows a one-time Accept URL you can copy — "Share this only if the email didn't arrive — anyone with the link who matches the invited email can accept."
- The accepting account's email must match the invited email — a forwarded link is useless to anyone else.
- Invitations expire (the expiry shows on each pending invitation) and can be revoked any time before acceptance.
- Accepting attaches the chosen policies and adds the member — it's idempotent, so double-clicks are harmless.
Custom policies
IAM → Policies is the escape hatch when the built-in roles
don't fit: define a policy from allow/deny statements over actions
(e.g. langsync:CreateTerm) and resources (a specific namespace, a
whole product, everything). Attach custom policies via the org-wide
invitation flow or directly to existing members.
The built-in roles are themselves just system-managed policies — the Translator role, for instance, is an inline policy generated from your namespace and language picks — so anything the products can check, a custom policy can express.
Auditability
Every IAM mutation — policies created or changed, roles attached or detached, members removed, invitations created / revoked / accepted / declined — is written to the organization's audit trail with the actor, IP, and timestamp, retained for one year.
Behaviour and edge cases
- New-member default: members join with exactly the policies their invitation carried — nothing implicit. (The org creator is the exception: they start as Owner.)
- Permission checks are cached briefly (about 15 minutes) by the products, so a role change can take up to that long to bite on actions the member was recently using.
- You can't remove your own last ownership in any way that orphans the org — org handover is a support flow ([email protected]), and account deletion refuses while you're the sole member of any org.
Related
- Organizations — the container all of this lives in.
- Product members pages: LangSync, Backup, and DomainRadar each link here from their Members sidebar entry.