Skip to main content
An Automation in Omneo is a query-driven Reaction. It runs a query to find a set of subjects, then runs its actions once for each one. A schedule decides when the query runs. Automations are the reaction type to reach for when no single event announces the thing you care about.

​
Why a query, not an event

A Trigger is handed its subject by the event that fired it. An Automation fires on a clock, and a clock carries no subject, so it has to go and find them. That lookup is the query, and it is required on every Automation. This is also why some rules can only be an Automation. There is no “customer became lapsed” event, because lapsing is the absence of activity, and absence never fires anything. Only a query can find it. The same goes for “birthday next week” and “reward expires in 14 days”: both are conditions about the calendar rather than about something that just happened.

​
How an Automation runs

  1. The schedule comes due, either a recurring slot or a specific date.
  2. Omneo runs the Automation’s query with its arguments.
  3. For each row the query returns, the action chain runs once.
A run with no matching rows completes having done nothing, which is normal and not an error.

​
What an Automation is made of

For the full list of queries and their arguments, see Automation Queries.

​
What the query returns

Most queries return profiles, so the action chain acts on a profile. Some return another object instead, for example a list definition or a reservation, and the chain acts on that. Several queries also pass a calculated value through to the actions, such as a spend total you can turn into a proportional reward.

​
The same queries back dynamic groups

A query is not tied to Automations. A dynamic group configures its candidate query the same way, with the same query name and the same { name, value } arguments, resolved from the same set. lapsed with days: 90 means the same thing in both places. What differs is what the result is used for: One constraint applies to groups only: a dynamic group’s candidate query must return profiles, because membership is a set of profiles. Queries returning other objects work in an Automation but are rejected on a group.

​
Testing before it runs for real

An Automation can be dry run, reporting who it would have matched and what its actions would have done, without issuing anything. Most queries support this. See Automation Dry Run Result API.