Role Grant
What It Is
This retained record is superseded by the User Account concept, which now owns its facets.
A role grant applies an access definition to a subject, a scope and an optional period. It turns a reusable job description into an assignment: one person can hold a role across the customer, while another holds it only in a chosen workspace. The role definition alone establishes no person's entitlement.
An ordinary assignment names an account. An automatic assignment can instead name a contact and reach the portal member linked to that person. Invitations offer grants that remain pending until acceptance, while active memberships can receive usable grants directly. Time windows can defer the start or end the assignment later.
The grant remains explainable after its active period. Withdrawn and ended assignments are retained as history, and changes can be reviewed in relation to both the grant and the person. This gives administrators a record of how access develops rather than only a snapshot of today's roles.
What It Is Not
A grant differs from its role definition and from the invitation that may offer it. A CRM responsibility does not itself authorize application use. Staff access has a separate request and consent record, although its usable authority is materialized through an ordinary role assignment. Licensing and application-access checks remain additional parts of authorization.
How It Is Used
Administrators assign a role from a person's access administration, choose where it applies and revisit that scope as work changes. A role can move between customer-wide access and selected workspaces without manually coordinating every individual assignment. Grant checks allow administrators to inspect whether a proposed delegation is permitted before writing it.
The access explanation connects allowed permissions to the definitions and assignments behind them. That explanation helps distinguish an absent grant from a conditional or denied permission. Automatic assignments direct administrators to change their source rather than edit the generated assignment by hand. Revocation changes stored authority immediately, but cached gateway decisions have their own expiry.
Its Facets
Scope. Customer, workspace, supported custom-record and staff-platform scopes determine where the definition counts.
State. Pending, scheduled, live, ended and withdrawn distinguish eligibility for current evaluation from retained history.
Window and conditions. Start and end times limit duration; supported conditions limit circumstances. A change to a deny can widen access even when its scope becomes smaller.
Automatic source. Derivation metadata explains which appointment or eligibility rule owns the assignment and how it is maintained.
Delegation safeguards. Widening checks prevent an administrator from handing out authority they cannot exercise. Last-administrator checks protect continued administration.
Security context and history. The context supplies evaluated access to the console. The trail explains changes and refusals, with sensitive invitation and password material excluded.
How It Relates
Each role assignment names its access definition and subject. Workspace scope connects the assignment to the association where work happens. Staff access materializes the same kind of authority without changing staff membership. A portal account's linked contact connects it to contact-keyed automatic assignments.
What It Could Become
The product should resolve whether generated assignments always belong to contacts or can belong to logins. Immediate revocation across cached requests requires a mechanism beyond the current flush submission. The product should make the origin of an assignment clear during access review, so administrators can distinguish a deliberate delegation from authority maintained by an appointment or eligibility rule.