Page body
Purpose
This page maps two role families used around the CRM:
- Documentation-access roles for the docs portal and editorial workflow.
- CRM operator roles used inside the Backoffice.
Both tables are derived from repo evidence (the editorial-experience and
draft-workflow architecture docs for doc access, and the staff module plus
surface docs for operator roles). Where a role is referenced as a functional
grouping rather than a concrete staff-role value, the table says so rather than
implying it is an enforced enum.
Documentation Access Roles
These roles govern who can see published docs and who can edit or approve content. Access is server-checked: viewer requests cannot mutate drafts even if they guess editorial URLs.
| Role | Can see | Can do |
|---|---|---|
| Viewer (operator) | The clean published portal at /docs/*. No reviewer-centric copy in the main shell. | Read published pages only. May see subtle Edit page affordances if they hold edit access, but cannot mutate drafts. |
| Editor | Published page plus the full-page editing surface at /editor/*. | Create and edit drafts, prepare page body and structured sidecar changes together, and treat screenshots (including focusRegion) as first-class draft changes. |
| Reviewer | The reviewer workflow at /drafts/*, including the draft activity timeline. | Compare a draft to current Git-backed content, leave summary and targeted review comments, approve, and trigger sync to the Git branch. |
| Administrator / secret-link | Editorial surfaces reached through the docs-side bridge (/access/administrator?key=...&next=/editor/...). | Acts as an editor/reviewer bridge; the secret-link route mints a short-lived reviewer cookie and history records the actor provenance as secret_link. |
Practical rule: editorial and reviewer language stays out of the operator
/docs/* shell; it is only allowed in editorial (/editor/*) and review
(/drafts/*) modes.
CRM Operator Roles
These are the operator roles used inside the Backoffice. The staff module is
the source of truth for the concrete role tiers; the create form hardcodes its
visible role choices and enforces a role hierarchy.
| Role | Evidence | Can see / do |
|---|---|---|
| SUPERADMIN | staff create service forbids creating the SUPERADMIN role directly. | Top access tier; not creatable through the normal create flow. |
| Admin / Administrator | staff detail and list surfaces describe the admin account, role name, group, and permission matrix. | Full admin account with a stored category-by-category permission matrix. |
| Manager | staff create form exposes Manager as a visible role; group editing is enabled when the edited staff role is Manager. | Operator role that can be created and can have group assignment edited. |
| Support | staff create form exposes Support; support users get a parent-admin link, and edit mode shows the parent-admin field as read-only. | Scoped operator role tied to a parent admin. |
Functional operator groupings
The following are referenced in surface docs as functional operator groupings
or actor descriptions rather than as concrete staff role-enum values. They are
illustrative of who works a surface, not authoritative role records.
| Grouping | Evidence | Typical scope |
|---|---|---|
| Risk / fraud operators | players/tabs/fraud-detection traces MaxMind fraud-check, risk-score, and risk-band surfaces; docs name support and fraud/risk teams as a docs audience. | Work the fraud-detection tab and risk-scoring surfaces. |
| Payments operators | A bonus action business_meaning states it "Allows a payment operator to approve a pending payment after review." | Approve or process pending payments and related withdrawal review. |
Practical rule: when documenting who can act on a surface, use the concrete
staff role tiers (SUPERADMIN, Admin, Manager, Support) for access claims, and
treat risk/payments as functional groupings unless a surface evidences them as
enforced roles.
How to use this page
- For docs-portal questions, use the documentation-access table.
- For Backoffice access claims, use the concrete operator role tiers.
- Before asserting that a functional grouping (risk, payments) has enforced permissions, verify the exact surface rather than relying on this label.