Roles and Access

In short. SGEN uses two independent tiers of authority: account-tier (managed in SG-Dashboard — billing, provisioning, multi-site visibility) and site-tier (managed in SG-Admin — content, modules, publishing on one site). Account-tier role does not auto-grant site-tier role. Each is assigned explicitly, and every grant or revoke is audited. The role catalog: Account Owner / Admin / Member at the account tier; Site Owner / Editor / Author / Viewer at the site tier.

On this page: Two tiers of authority · Account-tier roles · Site-tier roles · Permission scope per operation · Role assignment model · Constraints and boundaries · Related reading

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. This page defines 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.

Read this alongside Environments and Site States and Publishing Model. The three form the operating model: environment-and-state defines where, publishing defines operations, and roles-and-access defines who is permitted to run them.

Two tiers of authority

A role in SGEN is a named permission scope granted to an operator at a specific tier. 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 is the level of authority a role applies to. The two tiers are independent — an operator granted authority at the account tier is not automatically granted authority on individual sites. This separation keeps account-tier authority (billing, multi-site visibility) distinct from per-site authority (publishing, content, modules).

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.

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 the original account holder receives when an account is provisioned — typically one or two per account.

Account Admin has most of the Account Owner's authority with a narrower scope on high-stakes operations. Account Admins handle day-to-day account operations and assist the Owner with the account user roster; certain account-life operations (closing the account, transferring ownership) remain Owner-only.

Account Member has read-oriented account-tier authority. They can see the per-site list and account-tier reporting, but cannot manage billing, provision sites, or modify the account user roster. Intended for stakeholders who need account-tier visibility without 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 SG-Admin. Site-tier role assignment is per-site; an operator who is Site Owner on Site A does not automatically have any authority on Site B, even if they are also an Account Owner.

Site Owner has full authority on the assigned site — every module, publish and promote operations, per-site user roster, and per-site settings. Authority is per-site.

Site Editor has full editorial authority — author, save, publish, and promote records. Can manage content across modules but typically does not manage the per-site user roster or infrastructure settings. The most common day-to-day operator role.

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

Site Viewer has read-only authority on the assigned site — can see records, audit trail entries, and the administrative surface, but cannot save, publish, promote, or modify settings. Intended for stakeholders and analytics-focused operators who need visibility without write authority.

Permission scope per operation

The matrix maps the most common operator workflows to the role tier and role designation typically required to run them. Uses 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 SG-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 granted Site Editor on Site A is not, by that grant, authorized on Site B. Each per-site role grant is its own audited event. This per-site scoping is how 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 same audit surface that publishing-related events use, so a single query can correlate publish events with the role grants that authorized them.

Constraints and boundaries

• 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, letting reviewers correlate authority changes with the operations they enabled.
• Authentication is separate from authorization. Logging in proves identity; role assignments determine what that identity can do. Identity changes (password reset, MFA enrollment) are separate from role changes.

Examples

An Account Owner who cannot edit pages. A new Account Owner opens a site and cannot edit a page — they are not in the per-site roster. The account-tier role does not auto-grant a site-tier role. They open SG-Admin user management, grant themselves Site Editor, and the grant is an audited event from that moment forward.

A contributor who should not ship to live. The Site Owner grants a new contributor Site Author. They can create and save post drafts on staging but cannot publish or promote to live. A Site Editor reviews each draft and promotes it. The audit trail records the contributor's saves and the editor's promote events as a sequence with each operator's identity preserved.

Revoking a departed operator. When an operator leaves, the Site Owner revokes their site role and the Account Owner revokes their account role. Both revoke events are audited. Subsequent access attempts are denied; the identity (login) still exists, but with no role assignments the authority is empty.

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.

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 — account-tier and site-tier roles are assigned independently, with no cross-tier auto-grant.
• Per-site scoping — 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; 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 — 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).