Templates

Author the permission bundles you assign to members. Edit, archive, and delete templates.

Templates are named bundles of capabilities. You author them once, assign them to members, and adjust later as your team's responsibilities shift. A template change immediately affects every member who holds it.

Only the vault owner can create, edit, archive, or delete templates. Members never edit templates, even with the broadest non-owner template assigned — modifying a template is the meta-power that gates every other capability grant, and we keep it owner-only on principle. The Capabilities reference lists every cell you can check in a template.

Authoring a template

From Organization → Templates, click New template. A template needs a name (unique among your active templates) and a set of capability checks across the matrix.

The matrix is grouped by category: Machines, Enrollment tokens, Audit log, Alerts, IP allowlist, Integrations, Trash, Organization, Templates, Support, Projects, Secrets, Policies, Project machines. Each category has a few checkable cells. Some cells are vault-wide (a single permission applies across the whole vault); some are project-scoped (the same permission, scoped to projects the member has access to).

Three cells in the matrix are owner-only:

  • Templates: Manage — edit templates and their capability grants.
  • Organization: Assign templates — change which template a member holds.
  • Organization: Change member scope — change which projects a member is scoped to.

The matrix shows these cells as locked. Checking them on a template has no effect: the template can be saved, but the cells are filtered out before the template is rendered to anyone. The reason is privilege escalation: a non-owner who could change another member's template (or their own) could promote themselves past the owner's intended grant. Owner-only keeps that surface inaccessible to delegated admins.

Editing a template

Open a template from the templates list and change any of: name, description, or capability checks. Each capability checked or unchecked writes an append-only audit row in the template-capability audit log, capturing who changed what and when. The audit rows are never deleted — even when the template itself is hard-deleted later, the trail of changes stays.

A template change takes effect on the next request from every member who holds the template. There is no separate "publish" step; the matrix is the source of truth.

Archiving a template

Archive is a soft-hide. The template stays in the database, but it stops appearing in the editor's default view and stops being available for new assignments. Existing assignments would normally continue to resolve against it — but to keep the verb honest, we block archive when members are still assigned. Reassign every member off the template (to another template or to none) before you archive, and the action will succeed.

To restore an archived template, switch the templates listing to Archived filter, open the template, and unarchive it. Restoration is allowed only if the name is still unique among active templates; if you've created a replacement template with the same name, rename it first.

Deleting a template

Hard delete is the irreversible version of archive: the template row is dropped from the database. Same gate — no members assigned. The capability-change audit rows survive the delete (the audit table is append-only and immutable), so a forensic reviewer can still see what the template used to grant.

In practice you'll rarely hard-delete. Archive is the right choice if there's any chance you'll want the template back; hard delete only when you're sure it's not coming back and you don't want the row in your editor at all.

Capability changes on a live template

If a member holds a template and you remove a capability from it, the member loses that capability on their next request. If you add a capability, they gain it on their next request. No re-login or re-acceptance needed.

This makes templates the natural place to tune access without touching individual members. If three engineers need stricter audit access, change the template they all share rather than walking each member row.

Where to next