Roles & permissions
Every assistant action runs as a specific user, and that user's roles decide exactly what it may touch. Permissions are checked before every write — a denied action is refused out loud, never worked around.
How rules work
A role is a set of rules. Each rule combines:
- Environments — production, staging, or both.
- A match — any combination of a path pattern (e.g.
/insights/**), a page type (e.g.blogPost), and a slug pattern (e.g.annual-report-*). Content routes and code paths live in the same system. - Actions — create, read, update, delete, publish.
A write is allowed if any rule grants that action with every part of the match satisfied. This lets you express
things like "can edit blog posts on staging but publish nothing", or "developer access to src/** on
the staging branch only".
Default roles
New workspaces start with a sensible role set you can rename, edit or replace:
| Role | Scope | What it means |
|---|---|---|
| Site Admin | Everything, plus team management | Full content actions everywhere, code access, and managing members & roles. |
| Insights Editor | /insights/** | Edit and publish within the insights/blog section. |
| Junior Writer | /insights/** | Edit only — works in drafts; publishing goes through approvals. |
| Services Manager | /services/**, /case-studies/** | Edit and publish within the services and case-study sections. |
| Developer | src/**, packages/**, apps/** | Code changes only — no content access. |
The publish gate
Publish is the action that controls what reaches your live site — and it gates more than the publish button. Editing a published document directly, or creating a document as published, changes live content immediately, so those also require publish permission. Users without it work in drafts and route changes through approvals.
Audit log
Every write — create, update, publish, delete, code commit, approval decision — is recorded with who did it, what it targeted (the canonical path), which environment, and when. Recent activity is visible in the portal's context rail; the full log backs your governance story.
Managing the team
Admins manage members and roles under Team & Roles in the portal: invite by email, assign roles, and build custom rules with the role editor. Guardrails apply — you can't edit your own roles, and platform-level roles can't be granted from the team screen.