> ## Documentation Index
> Fetch the complete documentation index at: https://docs.omneo.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Automations

> Query-driven Reactions: logic that finds its own subjects and runs against each one.

An **Automation** in Omneo is a query-driven [Reaction](/concepts/automation/reactions). 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](/concepts/automation/triggers) 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

| Field                    | Description                                                                                                   |
| ------------------------ | ------------------------------------------------------------------------------------------------------------- |
| `query`                  | The name of the query to run, for example `lapsed`. Required. This decides who the Automation acts on.        |
| `arguments`              | An array of `{ name, value }` objects tuning the query, for example `days: 90`. Each query validates its own. |
| `query_type`             | Optional label. It does not affect which query runs; the name alone selects it.                               |
| `type`                   | `scheduled` for a recurring Automation, or `date` for a one-off.                                              |
| `slot`                   | For `scheduled`: the time of day to run, as a slot handle.                                                    |
| `date`                   | For `date`: the day to run.                                                                                   |
| `frequency` and `run_at` | Narrow a `scheduled` Automation to weekly, fortnightly, or monthly.                                           |
| `taskable`               | How matches are processed.                                                                                    |
| `is_active`              | An Automation only runs when this is true.                                                                    |
| `actions`                | The ordered chain to run per matched row.                                                                     |

For the full list of queries and their arguments, see [Automation Queries](/dev-guides/reactions/automation-queries#query-reference).

## 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](/concepts/groups#candidate-query) 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:

|           | Automation                          | Dynamic group                                            |
| --------- | ----------------------------------- | -------------------------------------------------------- |
| Runs      | On the Automation's schedule        | When the group's snapshot is built                       |
| Result is | The subjects to run actions against | The candidate set, narrowed further by the group's rules |
| Query is  | Required                            | Required, and cannot be removed once set                 |

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](/api-reference/automation-dry-run-result/overview).

## Related

* [Reactions](/concepts/automation/reactions), the umbrella concept and the shared action layer
* [Triggers](/concepts/automation/triggers), the event-driven counterpart
* [Automation Queries](/dev-guides/reactions/automation-queries) for the query reference and scheduling detail
* [Groups](/concepts/groups) for the other consumer of these queries
* [Automation API](/api-reference/automation/overview)