Marketing Authorization Model
Authorization Boundary
Audience and list operations belong to an authorized workspace. Application entry and licensing come from Platform; resource operations then check their declared Marketing authority. The public health check is the anonymous exception and exposes no business records. Recipient calculation helpers are internal calls, and contact-merge participation is restricted to CRM’s database role. Scheduled recovery and count execution use machine entry points rather than public customer operations.
Rhythm staff enter a customer workspace through Platform’s customer-access grants and role assignments. Staff headquarters authority alone does not provide Marketing access. The delivery probe is an operations tool reached through cloud invocation authority, with no customer permission or console screen.
Scopes
Marketing declares its customer operation permissions at workspace level. An audience owner is accountable for a definition, but ownership is not an independent access grant. Source-record visibility remains a separate query-service boundary when a person evaluates an audience. Marketing declares no organizational-unit or per-audience permission grant.
Platform evaluates the caller’s workspace reach and signed authority. Existing gateway decisions can survive an access change for their cache lifetime, while staff-entry records describe a separate signed-authority expiry bound. Marketing relies on those Platform contracts; it makes no immediate-revocation promise of its own.
Roles
The three Marketing profiles describe the read, user and administrator tier policies inferred from the published permission declarations and Platform’s tier-generation contract. They are entitlement profiles within customer roles, rather than newly installed Marketing-specific roles. Read Only supports reach review; User adds preparation and manual group maintenance; Administrator adds sensitive contact-status inclusion.
Platform owns built-in and customer-defined roles, policy composition, assignments and revocation. Actual access depends on those assignments and their scope. Custom roles can separate audience management from list management; either permission can exist without the other. The profiles below do not establish a particular customer’s grants or prove that a release has reconciled them.
Permission Catalogue
| Permission | Intent | Tier | Additional Boundary |
|---|---|---|---|
| marketing.application.access | Open the application. | Read | Workspace reach and licensing. |
| marketing.audiences.view | Read definitions and evaluations; request previews and counts. | Read | The evaluator’s source-query authority. |
| marketing.audiences.manage | Maintain, retire and take ownership of audiences. | User | Current version, record state and sensitive-change checks. |
| marketing.audiences.include-excluded-statuses | Permit newly enabled exceptional contact-status inclusion. | Administrator, sensitive | Audience management and explicit confirmation. |
| marketing.lists.manage | Read and maintain lists and memberships. | User | List state, edit version and membership validation. |
Contact query authority is an external prerequisite held independently of the Marketing profiles. The structured catalogue also retains the service contracts’ exact public and internal access declarations as marked boundary entries. These declarations are not grantable customer permissions.
The structured catalogue associates each key with its operations, surfaces and additional rule references. Application access has no dedicated Marketing HTTP operation. Background count execution inherits an authorized submission and retains the requester for source queries. Cloud invocation and CRM database execution are separate machine boundaries, not additional customer permission keys.
Role Entitlement Matrix
| Permission | Read Only Profile | User Profile | Administrator Profile |
|---|---|---|---|
| marketing.application.access | Yes | Yes | Yes |
| marketing.audiences.view | Yes | Yes | Yes |
| marketing.audiences.manage | — | Yes | Yes |
| marketing.audiences.include-excluded-statuses | — | — | Yes |
| marketing.lists.manage | — | Yes | Yes |
| crm.contacts.query | Separate grant | Separate grant | Separate grant |
This matrix describes the cumulative tier profiles. A custom role’s policy composition can differ, and a sensitive permission alone supplies no general audience editing authority.
Protected Actions
Sensitive inclusion combines audience management, the sensitive grant and the confirmation guard defined in the audience contracts. Takeover uses ordinary audience management in the present contract; the open product question considers whether unilateral takeover needs narrower authority. Archiving and replacing a saved-query copy use the version and state guards of their owning capabilities. List membership changes use the list’s state and uniqueness guards.
CRM merge participation, scheduled recovery and the delivery probe have distinct machine boundaries. None provides a shortcut for a customer caller to acquire broader source-record access.
Guards Distinguished From Permissions
A permission establishes whether a person may attempt an operation. A guard evaluates the particular record, requested change or source visibility after that authority is established. Workspace isolation, archive state, version comparison, confirmation and dataset query access serve different purposes and remain separately identified in the structured catalogue.
Hiding an action in the console helps a person understand available work, but the service still enforces the operation boundary. The existing editor finding records controls that remain interactive in read-only states; the authorization model does not treat their presentation as proof of server authority.
What People See When Refused
The console hides inaccessible Marketing screens and presents a refusal page for list access without authority. A readable audience can appear with editing restricted. Attempts to enable sensitive inclusion without authority or confirmation produce distinct permission and validation refusals. A stale write produces a conflict, while an unavailable workspace record is reported as not found.
A preview refused by source-query authorization explains that the person cannot query the audience’s records. A complete count can be accepted first and later show that same permission failure as its failed outcome. Neither refusal is shown as an empty successful audience. Temporary source-service failures follow retry and unavailable-result handling. The findings record remaining limits in error redaction and failure settlement.