Concepts

Workspaces

A workspace is your organisation (or team). Templates, plans, members, API tokens, webhooks, SSO and the audit log all belong to one workspace and are never shared between workspaces. A user can be a member of several workspaces.

Roles

A member can hold several roles at once.

Role	Can
Viewer	Read-only: view plans, steps and status. Viewers are free (they don't count as seats).
Approver	Approve or reject plans and steps; create plans from a template; work on steps; mark a plan rolled back.
Template manager	Create, edit and archive templates; create plans; work on steps.
Admin	Invite people, assign roles, manage connections (API tokens, webhooks), SSO and billing; create plans; mark rolled back. An Admin cannot approve unless also Approver.

Only Approvers can approve. Approvals always stay with people: neither the API nor the MCP server can approve.

Templates

A template is a reusable checklist: an ordered list of steps per phase. Saving a template creates a new version; plans copy (snapshot) the steps of the current version, so later template edits never change running plans. Archived templates can't be used for new plans. Every template has a stable Template ID (shown with a copy button) that stays the same when you rename it.

Plans

A plan is one release, created from a template, with a name, an environment (free text, e.g. production, staging) and optional CI metadata (repository, ref/tag, commit, run link) when created through the API.

Phases

Every step belongs to one of three phases that run in order:

1. Before deployment (before): preparation, reviews, rollback plan, backups.
2. During deployment (during): go/no-go, trigger the deploy, watch it, smoke tests.
3. After deployment (after): health checks, release notes, sign-off.

A phase is unlocked once every step of all earlier phases is resolved (approved, or skipped when optional).

Steps: required and optional

• Required steps must be approved. They can never be skipped.
• Optional steps can be approved or skipped; a skip is proposed with a reason and needs the same approvals as an approval would.

Working a step: someone with a working role submits evidence (a link or note), then Approvers approve or reject it (a rejection needs a comment and sends the step back).

Approvals and four-eyes

• Plan approval: a proposed plan needs 1 approval (2 with plan-wide four-eyes) before work starts. Rejecting needs a comment; the plan can then be fixed and re-proposed (a new round).
• Plan-wide four-eyes: every approval on the plan (the plan itself and every step) needs two different Approvers, and the person who proposed the plan cannot approve it.
• Per-step four-eyes: when plan-wide four-eyes is off, individual steps can still require two approvers (set per step in the template, and adjustable when creating a plan). The person who submitted the evidence for such a step can't approve it.

Plan statuses

Status	API planStatus	Meaning
Proposed	waiting_for_approval	Waiting for the plan to be approved.
Rejected	rejected	The plan was rejected; fix and re-propose it.
In progress	in_progress (or waiting_for_approval while a step waits for approval, rejected when a step is rejected)	Steps are being worked on.
Done	done	Every step is resolved. Set automatically when the last step is approved or skipped.
Rolled back	rolled_back	Someone marked the deployment as rolled back (with a reason).

Audit log

Every decision, change, token, SSO configuration and sign-in via SSO is written to the workspace audit log with who, what and when.