Roles and Access

How SGEN models who can do what — and the boundary between account-tier and per-site authority.

SGEN's roles-and-access model defines two tiers of authority — account-tier at SG-Dashboard and site-tier at SG-Admin — and a small set of role designations within each tier that describe what an operator is permitted to do. This page is the shared definition of how those tiers and roles fit together, what each role can and cannot do, how role assignment works, and how the audit posture handles permission-related events.

This page is read alongside Environments and Site States and Publishing Model. The three together form the operating model: environment-and-state defines the where, publishing defines the operations, and roles-and-access defines who is permitted to run them. Every Guide that walks through an operation assumes this model.

What is this for?

Read this page when you want the shared model behind permissions in SGEN. It defines the two tiers of authority, names the role designations available at each tier, lists the operations each role is permitted to run, and explains how role assignment behaves when an operator works across multiple sites under the same account.

The page is a Reference definition. It does not walk you through assigning a specific user a specific role — those procedures live in Guides. It also does not enumerate per-customer permission overrides; that detail lives in internal operational documentation or in the customer agreement.

Good use cases

• You are new to SGEN and want the permission model explained before you click anything that says "Add User."
• You are scoping an operations team and need to know which tier each operator should be granted authority on.
• You are working through a multi-site account setup and need to understand why an account-tier role does not auto-grant per-site access.
• You are debugging a "this operator cannot publish" question and want the structural model behind permission denials.
• You are designing internal SOPs around least-privilege access and need the role catalog to anchor the policy.
• You hit a "can a Dashboard user edit pages?" question and want the tier boundary explained in operator language.

What NOT to use this for

• Step-by-step procedures for adding or removing users — open the relevant Guide.
• Per-customer permission overrides — internal-only documentation or support escalation.
• API-tier authentication detail — open Developer Reference if available.
• Per-release shipped behavior change — open What's New or Changelog.

How this connects to other features

• Environments and Site States — the where-and-state coordinates that role permissions act against.
• Publishing Model — the operations that role permissions govern at the per-record level.
• Shared Concepts Index — sibling concept pages.
• SG-Dashboard Overview — the account-tier surface where account roles are assigned.
• SG-Admin Overview — the per-site surface where site roles are assigned.

Definition

A role in SGEN is a named permission scope that an operator is granted at a specific tier of authority. The role determines what operations the operator can run within that tier and on records inside its scope. Roles are platform-defined; operators do not assemble custom permission sets at the operator tier in v1, though per-customer overrides are available through the customer agreement.

A tier in SGEN is the level of authority a role applies to. There are two tiers — account-tier at SG-Dashboard and site-tier at SG-Admin — and they are independent. An operator who is granted authority at the account tier is not automatically granted authority on individual sites; the per-site role assignment is a separate operation. This separation is structural — it lets account-tier authority (billing, multi-site visibility) stay distinct from per-site authority (publishing, content, modules).

Purpose

The purpose of this page is to give operators a stable, shared model of roles and access so that every Guide that mentions permissions can use the same vocabulary. Without that shared model, "admin" gets confused with "owner", "dashboard user" gets confused with "site user", and "publisher" gets treated as a global role rather than a per-site role.

Scope

This page covers the roles-and-access model at the shared-concept level — the structure rather than the procedure.

The page covers:

• The two tiers of authority and their boundary.
• The role catalog at each tier.
• The permission scope each role grants.
• The role-assignment model and how it behaves across multiple sites.
• The audit posture for permission-related events.

• Step-by-step user-management procedures — open the relevant Guide.
• Per-customer permission overrides — internal-only documentation.
• API-tier authentication and token management — open Developer Reference if available.
• Per-release shipped behavior change — open What's New or Changelog.

Account-tier roles

Account-tier roles govern authority over the account itself — billing, per-site provisioning, account-level reporting, and the account user roster. They live in SG-Dashboard. Account-tier authority does not, by itself, grant operations on individual sites' content or modules; per-site authority is assigned separately at the site tier.

Account Owner

The Account Owner has full authority at the account tier. Owners can manage billing, provision new sites, manage the account user roster, and assign account-tier roles to other users. Account Owner is the role that the original account holder receives when an account is provisioned, and it is intended to remain a small role count — typically one or two operators per account.

Account Admin

Account Admins have most of the Account Owner's authority but with a narrower scope on a small set of high-stakes operations. Account Admins can manage day-to-day account operations and assist the Owner with the account user roster, while certain account-life operations (closing the account, transferring ownership) remain Owner-only.

Account Member

Account Members have read-oriented account-tier authority. They can see the per-site list and account-tier reporting, but they cannot manage billing, provision sites, or modify the account user roster. Account Member is intended for stakeholders who need account-tier visibility without account-tier write authority.

Site-tier roles

Site-tier roles govern authority over a single site — its content, modules, publishing operations, and per-site user roster. They live in the admin. Site-tier role assignment is per-site; an operator who has Site Owner authority on Site A does not automatically have any authority on Site B under the same account, even if they are also an Account Owner.

Site Owner

The Site Owner has full authority on the assigned site. Owners can manage every module, publish and promote any record, manage the per-site user roster, and configure per-site settings. Site Owner authority is per-site — assigning Site Owner on Site A does not affect Site B.

Site Editor

Site Editors have full editorial authority — they can author, save, publish, and promote records. They can manage content across modules but typically do not manage the per-site user roster or per-site infrastructure settings. Site Editor is the most common day-to-day operator role.

Site Author

Site Authors can create, edit, and save records, but the publish and promote operations are typically gated to a higher role for review-required workflows. Site Author is intended for contributors who write into the system but do not directly ship to end users.

Site Viewer

Site Viewers have read-only authority on the assigned site. They can see records, audit trail entries, and the per-site administrative surface, but they cannot save, publish, promote, or modify settings. Site Viewer is intended for stakeholders, reviewers, and analytics-focused operators who need visibility without write authority.

Permission scope per operation

Different operations require different permission scopes. The matrix below maps the most common operator workflows to the role tier and role designation typically required to run them. The matrix uses the default permission scopes; per-customer overrides may extend or narrow individual scopes.

Role assignment model

Role assignment in SGEN is explicit. There is no implicit grant from one tier to the other, no role inheritance from account-tier to site-tier, and no automatic role grant when a new site is provisioned. Each role grant is a recorded operation with operator identity and timestamp.

Per-tier assignment

Account-tier roles are assigned in SG-Dashboard by an Account Owner or Admin. Site-tier roles are assigned in the admin by a Site Owner. The two assignment surfaces are independent — granting an account-tier role does not appear in any per-site roster, and granting a per-site role does not appear in the account-tier roster.

Per-site scope

Site-tier roles are scoped to a single site. An operator who is granted Site Editor on Site A is not, by that grant, granted any authority on Site B. Each per-site role grant is its own audited event. This per-site scoping is the structural way SGEN keeps multi-site accounts compartmentalized.

Audit signature

Every role grant and revoke is recorded in the audit trail with operator identity, target user identity, target tier, target role, and timestamp. The audit record sits in the same audit surface that publishing-related events use, so a single audit query can correlate publish events with the role grants that authorized them.

Constraints and boundaries

Some properties of the roles-and-access model are structural and worth naming explicitly so operators do not assume otherwise.

• Tiers are independent. Account-tier authority does not grant site-tier authority and vice versa. Each tier role is assigned explicitly.
• Per-site scoping is the default. A site-tier role grant on Site A does not affect Site B even when both sites belong to the same account.
• Roles are platform-defined. v1 ships a fixed role catalog. Per-customer overrides exist but go through the customer agreement, not the operator-tier surface.
• Role assignment is audited. Grant and revoke events sit in the same audit trail as publishing events, which lets reviewers correlate authority changes with the operations they enabled.
• Authentication is separate from authorization. A user logging in proves identity; the role assignments determine what that identity can do. Identity changes (password reset, MFA enrollment) are separate from role changes.

Examples

Example 1 — A new agency principal staffing two sites

An agency principal opens a new SGEN account and provisions two client sites — Site A and Site B. As Account Owner, they can see and manage both sites at the Dashboard tier. To author content on Site A, they grant themselves Site Editor on Site A explicitly. To do the same on Site B, they grant themselves Site Editor on Site B. The two grants are independent audit events. They are now Account Owner + Site Editor (A) + Site Editor (B).

Example 2 — A content contributor who should not ship to live

A new contributor joins to write blog posts. The Site Owner grants them Site Author on the site. The contributor can now create and save Post drafts on staging but cannot publish or promote them to live. A Site Editor reviews each draft, publishes on staging, and (after approval) promotes to live. The audit trail records the contributor's saves and the editor's publish + promote events as a sequence with each operator's identity preserved.

Example 3 — A stakeholder who needs read-only multi-site visibility

A stakeholder needs to see all account sites' analytics without authoring any content. They are granted Account Member at the account tier. They can open SG-Dashboard and see the per-site list and reporting. On individual sites, they are granted Site Viewer where appropriate. They have read access without any write authority across the account.

Example 4 — Why an Account Owner cannot edit pages by default

A new Account Owner is surprised when they open a site and cannot edit a Page. They check the per-site roster — they are not listed. The account-tier role does not auto-grant a site-tier role. They open the admin user management, grant themselves Site Editor on the site, and now they can edit. The grant is an audit event that pairs to the moment they started editing.

Example 5 — Revoking access for a departed operator

An operator leaves the team. The Site Owner opens the per-site user roster and revokes their site role. The Account Owner opens SG-Dashboard and revokes their account role. Both revoke events are audited. Subsequent attempts by that operator to access either tier are denied; their identity (login) still exists but with no role assignments their authority is empty.

Example 6 — Auditing who promoted a high-stakes change

A regulator-facing change went to live. A reviewer opens the audit trail for the affected record, finds the promote event with operator identity, and cross-references the same operator's role-grant history to confirm they had the required Site Editor authority at the moment of the promote. The cross-reference is a single audit query; the platform stitches the role-grant timeline and the publishing timeline together.

Documentation guidance

This page is the shared definition of roles and access. Use it as the vocabulary anchor when other Guides reference "user", "role", "permission", "account-tier", "site-tier", "owner", "admin", "editor", "author", or "viewer". Per-area Guides describe how role assignments are operated inside specific surfaces; this page describes what the roles are and what authority each one carries.

For step-by-step procedures (how to add a user, how to grant a role, how to revoke access), open the relevant area Guide. For the operations the roles authorize, open Publishing Model. For the where-and-state coordinates the operations act on, open Environments and Site States.

Reading order

If you are new to SGEN, read Environments and Site States first, then Publishing Model, then this page. The three together form the operating model that every other Guide assumes. If you arrived here from a "permission denied" or "this user cannot do X" question, this page plus Publishing Model explain the structural answer.

Related reading

• Environments and Site States — coordinates that role permissions act against.
• Publishing Model — operations that role permissions govern.
• Shared Concepts Index — sibling concept pages.
• SG-Dashboard Overview — account-tier surface where account roles are assigned.
• SG-Admin Overview — per-site surface where site roles are assigned.
• Welcome to SGEN Docs — start-here landing.

Vocabulary cross-reference

• Tier — the level of authority a role applies to (account-tier or site-tier).
• Role — a named permission scope within a tier (Owner, Admin, Editor, Author, Viewer, Member).
• Account-tier — authority over the account itself (billing, per-site provisioning, account roster).
• Site-tier — authority over a single site (content, modules, publishing, per-site roster).
• Per-tier assignment — the principle that account-tier and site-tier roles are assigned independently, with no cross-tier auto-grant.
• Per-site scoping — the principle that a site-tier role on Site A does not extend to Site B.
• Platform-defined role — a role designation shipped by the platform with a fixed permission scope; v1 does not expose operator-tier custom permission sets.
• Per-customer override — an extension or narrowing of the default scopes negotiated through the customer agreement.
• Authentication — proving identity (login, password, MFA).
• Authorization — what the proven identity is permitted to do (the role assignments).
• Grant — the operation that adds a role to a user; audited per event.
• Revoke — the operation that removes a role from a user; audited per event.
• Account Owner — full account-tier authority; typically one or two per account.
• Site Owner — full site-tier authority on the assigned site; per-site roster + settings.
• Site Editor — full editorial authority on the assigned site; can publish and promote.
• Site Author — create + save authority on the assigned site; publish gated to higher role.
• Site Viewer — read-only authority on the assigned site; no write capability.
• Audit trail — the platform-managed record of grant, revoke, publish, and promote events.
• Least-privilege — the design principle of granting the smallest role that lets an operator do their work.
• Identity — the unique user record that holds the login (email, MFA enrollment, account history); persists across grant and revoke.
• Authority — the operational reach the identity has at any moment; equals the union of all currently active role grants.
• Empty authority — the state of an identity that exists but has no active role grants; can log in but cannot perform any operations.
• Cross-tier audit query — a single audit query that joins role-grant events with publish or promote events; supported by the unified audit surface.
• Onboarding-by-grant — the model where a new operator's effective access is configured by granting one or more roles, rather than by toggling individual permissions.
• Offboarding-by-revoke — the symmetric removal model; a single revoke event per granted role brings authority back to empty.
• Roster — the per-tier list of identities that have at least one active role at that tier (account roster vs per-site roster).