Entitlement
What It Models
An entitlement records a usable benefit held by a contact or organization. Purchases can grant downloads, included registrations, submission requirements or access; staff can also create a grant manually. Consumers draw units, and staff interventions can restore consumption or revoke a right.
Identity and Attributes
A grant identifies holder, product, kind and origin, then records its allowance and validity window. Unlimited benefits omit the finite allowance. Each consumed unit retains the consumer's reference and attribution, including restoration information when staff return that unit.
Relationships
Purchased grants point to the line and obligation whose frozen payload supplied their specification. Subsequent product configuration does not rewrite the grant. Holders remain CRM records, and eligibility obtains Commerce's active-rights projection.
Invariants
Constraints enforce line-and-kind uniqueness, finite allowances, timestamp consistency and valid windows. The consumption function checks active status and time bounds while protecting replay and concurrent allowance use. Revocation preserves past consumption.
How It Is Stored and Shared
Entitlements owns both grants and their use records. Consumers invoke the database consumption boundary inside their own transaction, under a dedicated execution role. Eligibility reads a view, and purchased-grant activity contributes to order history. No custom-field capability is declared.
Open Design Questions
The console has no grant-configuration screen. Live Order 360 supplies no entitlement records, leaving its tab empty. Submission-requirement benefits exist in the contract, but the consuming workflow needs integration outside this module.