Governance
Offer Lifecycle Governance
An offer is managed as a single configuration object carrying its lifecycle state, eligibility rules, priority and consumption caps together. Toggling the state controls whether the offer is eligible to be shown; the same configuration enforces spend, redemption and stock limits in real time as each customer is evaluated, with role-based control over who can create or change it.
This page answers
- What lifecycle states can an offer have?
- Who can create or change an offer?
- How are budget and inventory caps enforced?
- Is there an audit trail for offer changes?
More than an on/off switch
Enterprise offer programs need an offer to move through defined states, to be governed by who is allowed to change it, and to stop showing itself the moment its budget, redemption or stock limit is reached, without a customer ever being served an offer the business can no longer honour. Because state, targeting and stacking rules, priority and caps sit in one object, toggling the state controls eligibility everywhere the offer could be shown; no separate system has to stay in sync.
Lifecycle states
- DraftConfiguration is being built; not eligible to serve. Design updates apply freely.
- ScheduledConfigured and queued to activate at a future date and time; still editable.
- ActiveEligible to be shown; evaluated against targeting rules, priority and caps for every customer.
- PausedTemporarily withdrawn from eligibility without losing configuration, history or accumulated consumption counts.
- ExpiredPermanently past its eligibility window; retained for reporting and audit but no longer evaluated.
Externally defined offers
Where an offer's lifecycle is owned in an external loyalty or offer-management system, that system governs the state transitions and the platform reflects the current state via API, so targeting and messaging stay consistent with the system of record.
Approver gating and role-based control
Who can create, edit or remove an offer configuration is governed by the role-based permission model. Roles can be scoped so that a user can view an offer's configuration and performance without changing its rules, caps or state. Changes are versioned and timestamped: what changed, when, and by whom.
A formal multi-stage approver-gating step ahead of specific state transitions, such as senior sign-off before Draft becomes Active, can be scoped as part of implementation on top of this role and versioning foundation. It is not a native, out-of-the-box workflow today.
Budget and inventory guardrails
| Guardrail | How it works |
|---|---|
| Spend or redemption cap | A configured limit on total offer usage, checked against the current count at each customer evaluation. |
| Stock cap | A limit tied to available inventory, sourced from a near-real-time feed where stock truth sits in an external system. |
| Real-time consumption visibility | The current count updates as the offer is shown or redeemed, so the next evaluation reflects the latest state. |
| Auto-suppression | Once a cap is reached the offer is automatically excluded from further eligibility checks; no manual step required. |
Override and audit trail
Every change to an offer's configuration, state, rules, priority or caps is versioned and timestamped, including manual overrides such as raising a cap or reactivating a paused offer. Consumption approaching a configured cap can be surfaced as an alert ahead of the hard cutoff, so the offer owner sees it coming rather than finding out once it stops serving.
In TemasCRM
Every claim is compared with this product: what is live, what is partial, what is planned and what is not applicable by this product's design.
1 Live2 Partial3 Planned
- A lifecycle state on one configuration objectPartial
A campaign is a draft, then running, then done; only a draft is changed or deleted, and nothing schedules, pauses or resumes it. There is no separate offer object.
Campaigns - Approver gating before activationLive
A template is a draft until an ADMIN or a MANAGER approves it, and a campaign whose template is not approved is refused at the dispatch (template_not_approved); only an ADMIN or a MANAGER dispatches. A campaign has no approval request of its own, and the approvals screen is on the sample layer.
Templates - Consumption caps checked per evaluationPlanned
A coupon list counts what remains, computed from its codes and the issue ledger when asked; no campaign uses a pool, and spend caps on an offer are not modelled.
Coupon lists - Stock caps from an external feedPlanned
No inventory feed is connected; stock-aware suppression waits for a commerce integration.
- Versioned, timestamped audit trail of changesPartial
The audit log records campaign.create, campaign.update, campaign.delete and campaign.dispatch; only a draft is changed, so a dispatched campaign is a record.
Campaigns - Cap alerts ahead of the cutoffPlanned
The diagnostics board reports exhausted pools after the fact; an approaching-cap alert is not raised yet.