Reactors
Detailed reference for configuring reactors within Rule Based campaigns — triggers, conditions, reactions, activation limits, status, and editing behaviour.
Adding a reactor
From the Rule Based campaign detail screen, click Add Reactor to create a new reactor within the campaign.
Configuration
Each reactor requires the following:
Name & description (optional): Provide a name and description for the reactor. Both are designed to be shown to users.
Picture (optional): Upload an image to represent the reactor.
Event trigger — Select the event type that should trigger the reactor by clicking the cog icon in the Event Trigger block. This could be a purchase, referral, account creation, or any custom event type you’ve defined.
Conditions (optional) — Define criteria the event or user must meet for the reactor to fire. See Conditions.
Activation limits (optional) — Specify how many times the reactor can trigger, over what period, either per user or across all users in the program.
Reactions — Select the actions that should occur when the reactor is triggered — such as adjusting points, issuing a reward, or calling a webhook. See Reactions.
Event & reactor flow
When an event is reported to the Loyalty Engine, the following sequence occurs:
The engine identifies all active reactors that are listening for the reported event type.
For each matching reactor, conditions are evaluated against the event payload and user data.
Activation limits are checked and updated.
If all conditions pass, the configured reactions are executed.
Triggers
Each reactor listens for a single event type. When an event of that type is reported, the reactor evaluates its conditions and potentially fires its reactions.
Event types include both intrinsic events (built-in events like REGISTERED_ACCOUNT) and custom events (events you define).
See Event Types for more information on creating and managing event types.
Activation limits
Activation limits control how many times a reactor can trigger before it stops — either across your entire tenant, or on a per-user basis. Each limit applies over a time period you choose.
Limit period
When setting an activation limit, you specify the period the count resets against:
Lifetime
Never — the limit applies once for all time.
Daily
Each calendar day (00:00:00–23:59:59).
Weekly
Each calendar week (Monday–Sunday).
Monthly
Each calendar month (1st to last day).
Yearly
Each calendar year (1 January–31 December).
These are calendar periods — the count resets at fixed boundaries regardless of when the user first triggered the reactor. All periods are evaluated in UTC.
For example, a limit of “once per user, daily” lets each user trigger the reactor once between 00:00:00 and 23:59:59 UTC, and the allowance resets at midnight. A limit of “5 per user, monthly” resets on the 1st of each month.
Tenant activation limit
A tenant activation limit applies across your entire tenant: once the reactor has triggered its allotted number of times in the period, it stops running for all users until the period resets (or permanently, for a lifetime limit). When a tenant limit is in place, there is no limit on how many times individual users can trigger the reactor unless additional criteria are specified.
Subject activation limit
A subject activation limit applies per user: each user can trigger the reactor its allotted number of times in the period before it stops processing their events until the period resets. When a subject limit is in place, the tenant limit is unlimited, and the reactor runs indefinitely unless otherwise restricted.
Reactor lifecycle
A reactor has no lifecycle of its own — it’s managed entirely through its campaign. Reactors don’t have their own status, start date, end date, pause, archive, or clone actions.
A reactor’s timing comes from the campaign’s start and end dates.
Pausing the campaign stops its reactors from processing events; reactivating resumes them.
Archiving the campaign, or the campaign’s end date passing, stops its reactors.
Status (Active, Paused, Ended, Archived) is shown against the campaign, not against individual reactors or missions.
To duplicate a reactor’s setup, clone the campaign — individual reactors can’t be cloned on their own.
See Managing Campaigns for the full lifecycle.
Editing a reactor
A reactor's own configuration — its conditions, reaction, and reward — can be edited at any point in the campaign's life: Draft, Active, or Paused.
Editing is in place and non-destructive. It doesn't create a new version of the reactor or reset its participation history; the same reactor keeps its recorded participants.
What locks once the campaign is published is the campaign's structure. You can't add reactors, remove them, or reorder them on a live campaign — those changes can only be made in Draft. To change the reactor line-up on a live campaign, clone the campaign, amend the draft copy, and publish that. See Managing Campaigns.
FAQs
Can a reactor be triggered by multiple event types?
A single reactor listens for one event type. To create logic that requires multiple events to occur, use audiences to bridge them.
How do I avoid abuse or misuse?
Reactors without appropriate limits can be exploited — for example, a promo code reactor giving 500 points with no activation limit allows unlimited claims. Use activation limits, conditions, and points earning caps to mitigate this.
Can I set both tenant and subject activation limits at once?
Not directly. Set a tenant activation limit and use audience criteria to handle the per-user limit, as the Loyalty Engine doesn’t support both simultaneously.
What happens if I don’t set any activation limits?
The reactor runs indefinitely. That’s fine for some use cases (like baseline points earning) but can lead to misuse if not monitored.
How do I duplicate or end a reactor?
Both are campaign-level actions. To duplicate a reactor’s setup, clone its campaign. To end a reactor, archive or end its campaign or let the campaign’s end date pass. See Managing Campaigns.
Last updated
Was this helpful?