Skip to main content
Reactions are Omneo’s automation engine. A reaction evaluates conditions and executes a chain of actions against a subject. What supplies that subject is the whole difference between the two types.

​
Pick a type first

Choose by asking whether an event announces what you care about. “A transaction was recorded” is an event, so award the points from a trigger. “Lapsed for 90 days” is not an event, because lapsing is the absence of activity and absence fires nothing, so it has to be an automation with the lapsed query. Calling automations “scheduled reactions” understates the query. The schedule only sets when; the query sets who, and it is the part you configure. See Triggers and Automations for the concepts.

​
Anatomy of a reaction

A reaction has:
  • trigger: the event or schedule that fires the reaction
  • is_active: whether the reaction is enabled
  • actions: an ordered array of steps to execute, each with a sort_order
Actions run in sort_order sequence. If an action fails its condition (e.g., a filter action returns false), the chain stops.

​
Actions

Actions are shared between the two reaction types: the same set is available whether the reaction is a trigger or an automation, and they execute identically. Attaching one differs only in the endpoint you post to, /api/v3/triggers/{trigger}/actions or /api/v3/automations/{automation}/actions. For every action and its arguments, see Reaction Actions. Each action validates its own arguments and rejects the whole reaction on a bad payload, so a 422 on save usually means a missing required argument or a handle that does not exist. One behaviour matters when you order a chain: an action that returns false stops everything after it. That is how filter and the gate actions work, and it is why a filter is conventionally first.

​
Choosing a trigger event

A trigger listens for exactly one event, named in its trigger field. Every event that can be used is listed by domain on Triggers, and the payload each one carries is in Event Contexts. Two are worth knowing about before you pick:
  • profile.updated covers status and tag changes as well as field edits, and carries changes and originals so you can act on a transition rather than a state.
  • profile.before.update fires inside the update transaction, before the write, so its actions can influence what gets saved. Every other event reports something that already happened.

​
Data available in reactions

All reaction filters and actions have access to the Event Context for the triggering event. The context includes the profile, the triggering object (transaction, benefit, etc.), and related data. See Reaction Filters and JSON Conditions for how to access and evaluate this data.

​
Managing reactions

Reactions can be created and managed via the API (/api/v3/triggers) or via CX Manager under Settings → Reactions. A reaction must have is_active: true to fire.