Websites Authorization Model
Authorization Boundary
Published website browsing is public. Customer administration uses Platform authentication, workspace grants, application access and licence state. Staff-only site administration, onboarding, release-ledger operations and escalated review use system routes with staff authority. A customer administrator’s broad application role does not confer those staff powers.
Public integration routes have their own trust boundaries: callbacks and webhooks require valid signatures, while draft and design previews require their respective grants. A public route designation does not make protected drafts or pipeline mutation available to anonymous callers. Portal adapters use member sessions and leave final record authorization with CRM.
Scopes
Customer assignments may cover all applicable workspaces or selected workspaces. Workspace authority is narrowed by site and record checks where the operation requires them. An embedded editor session reaches one site. That restriction is a session guard, not a separately demonstrated site-role grant. Platform scope supplies staff authority; staff enter ordinary customer work through the separate consent-based access mechanism administered by Platform.
Roles
Administrator and Power User share the application powers relevant to Websites. Standard User and Read Only receive its reading tier. Portal Member alone supplies no demonstrated website-administration or CRM adapter grant in the pinned built-in role definition. The CRM keys requested by portal adapters require separate authority whose complete entitlement policy is outside this examination.
Rhythm Administrator holds staff administration, onboarding, release-ledger and Websites review authority while those declarations are active in the catalog. Support Representative and Software Engineer can inspect HQ sites without acquiring customer website access. Content editor and website change editor describe illustrative customer-defined profiles. They are not additional shipped built-ins. An assistant has no role of its own and uses the connecting person’s permissions.
Permission Catalogue
The grantable keys below come from service declarations or observed portal adapter requests. Operation references in the structured catalogue include both route permissions and additional authority evaluated by handlers. Application access is a separate gate rather than a substitute for an operation’s permission.
| Permission | Intent |
|---|---|
crm.organization-contacts.manage | Request additions, changes and removals on the member’s organization roster. |
crm.organization.read | Request the member’s organization and its roster through CRM adapters. |
crm.organization.update | Request changes to the member’s organization through CRM adapters. |
crm.self-contact-info.manage | Request changes to the member’s own contact points through CRM adapters. |
crm.self-contact.read | Request the member’s own profile and contact information through CRM adapters. |
hq.sites.manage | Maintain customer sites and addresses through staff routes. |
hq.sites.read | Inspect customer sites and addresses through staff routes. |
hq.web-releases.write | Read and maintain deployment, release and rollout records through staff routes. |
platform.sites.manage | Create sites and maintain their availability and web addresses. |
platform.sites.read | Inspect sites and their web addresses within the authorized workspace. |
platform.tenants.onboard | Prepare Websites and portal identity infrastructure through a staff operation. |
websites.application.access | Enter the Websites application when its licence and access checks allow it. |
websites.content.edit | Prepare site content, save drafts and obtain editorial previews. |
websites.content.publish | Make editorial content live, including settings and eligible page moves. |
websites.website-changes.change | Prepare design work, save revisions and obtain previews without publishing it. |
websites.website-changes.publish | Confirm publication of a specific website revision and retry eligible publication work. |
websites.website-changes.read | Inspect website changes, templates, content listings and delivery information. |
websites.website-changes.review | Decide escalated reviews and inspect or retry delivery work as Rhythm staff. |
websites.website-changes.rollback | Request recovery of the previous customer application release and retry recovery work. |
websites.website-changes.source | Authorize component-source edits within an otherwise authorized revision save. |
The structured catalogue also preserves the existing contracts’ combined permission expressions and access descriptors so every recorded operation can be reconciled without changing its contract. Those entries describe signatures, sessions, preview grants or evaluated combinations; they are not keys that a role can grant. CRM entries establish what the adapter requests, not a verified CRM policy or entitlement.
Role Entitlement Matrix
This matrix shows the area-relevant baseline of each role. It does not override narrower assignment scopes, deny rules, licensing or resource guards. The two editorial profiles are illustrative customer roles.
| Permission | Administrator | Power User | Standard User | Read Only | Portal Member | Rhythm Administrator | Support Representative | Software Engineer | Content Editor | Change Editor |
|---|---|---|---|---|---|---|---|---|---|---|
crm.organization-contacts.manage | — | — | — | — | — | — | — | — | — | — |
crm.organization.read | — | — | — | — | — | — | — | — | — | — |
crm.organization.update | — | — | — | — | — | — | — | — | — | — |
crm.self-contact-info.manage | — | — | — | — | — | — | — | — | — | — |
crm.self-contact.read | — | — | — | — | — | — | — | — | — | — |
hq.sites.manage | — | — | — | — | — | Allow | — | — | — | — |
hq.sites.read | — | — | — | — | — | Allow | Allow | Allow | — | — |
hq.web-releases.write | — | — | — | — | — | Allow | — | — | — | — |
platform.sites.manage | Allow | Allow | — | — | — | — | — | — | — | — |
platform.sites.read | Allow | Allow | Allow | Allow | — | — | — | — | Allow | Allow |
platform.tenants.onboard | — | — | — | — | — | Allow | — | — | — | — |
websites.application.access | Allow | Allow | Allow | Allow | — | Allow | — | — | Allow | Allow |
websites.content.edit | Allow | Allow | — | — | — | — | — | — | Allow | — |
websites.content.publish | Allow | Allow | — | — | — | — | — | — | — | — |
websites.website-changes.change | Allow | Allow | — | — | — | — | — | — | — | Allow |
websites.website-changes.publish | Allow | Allow | — | — | — | — | — | — | — | — |
websites.website-changes.read | Allow | Allow | Allow | Allow | — | — | — | — | Allow | Allow |
websites.website-changes.review | — | — | — | — | — | Allow | — | — | — | — |
websites.website-changes.rollback | Allow | Allow | — | — | — | — | — | — | — | — |
websites.website-changes.source | Allow | Allow | — | — | — | — | — | — | — | — |
A dash means the role definition or illustrative profile supplies no grant for that key. It does not establish a deny, and other valid assignments may add authority. Portal CRM entitlements are not established by this matrix. The permission and role rows carry the evidence for its entries.
Protected Actions
Publication requires confirmation of the current revision and readiness checks. Work classified for staff review waits for approval of that revision. Recovery targets the recorded previous customer application release and is restricted by the recovery workflow’s state. Retry evaluates publication or recovery authority according to the failed work even though its route opens with reading authority.
Source changes require source-edit authority in addition to the revision-saving route’s change grant. Content publication is independent of content editing. Settings saving publishes immediately; page moves and editor sessions evaluate publication authority separately. Assistant publication and recovery require a second call carrying a confirmation bound to the person and subject. That protocol alone does not prove a person approved the action.
Guards Distinguished From Permissions
A permission grants a kind of action. A guard decides whether that action is valid for the selected resource and its current state. Workspace ownership, the editor’s selected site, linked member identity, current revision, release ownership, template readiness, record version and lifecycle state are guards. Signed callbacks, content-reader credentials and preview grants authenticate integration or delegated access; they do not become assignable permission keys.
Platform may reuse gateway decisions for sixty seconds, with signed contexts lasting thirty seconds beyond that bound. The embedded editor instead carries its publication claim for a two-hour session without a fresh Platform grant check. The latter is a recorded control gap, not a promise of immediate revocation.
What People See When Refused
A missing operation grant produces a permission refusal. The editor explains that publishing requires publication authority and still permits a draft save. Foreign resources are generally presented as missing so the response does not disclose another workspace’s records; the module records paths whose narrower site guard is incomplete. Stale revisions and record versions require reloading or reconfirming current work.
A design preview link that is unknown answers Not Found; a revoked link answers Gone. Account sign-in uses the same error for an unknown address and an incorrect password. Member adapters translate missing authority into permission feedback and stale records into reload guidance. Assistant confirmation failures explain the invalid binding or expiry without returning the token’s contents, and unauthenticated assistant requests provide sign-in metadata.