Actions and automations

An action is a trigger plus an ordered list of steps. The trigger decides when it runs, the steps decide what happens, and each step's output flows into the next. Everything you can do by hand in the console — build a report, email it, post to Slack, move someone between groups — an action can do on your behalf.

Triggers

There are two kinds, and they answer different questions.

• On a schedule. Runs on a fixed cadence: every 5, 15 or 30 minutes, hourly, or daily, weekly and monthly at a time you set in your own timezone. Use this for reporting rhythms — a Monday morning exposure report, a monthly compliance pack.
• When activity matches. Runs off telemetry. You describe which events count using the same criteria you would write in Logs, and the action fires when they appear. Use this for response, not reporting.

A matching trigger fires in one of three ways. Every matching event runs once per event and acts on the user who caused it. When a user crosses a threshold counts per person over a rolling window — three critical blocks in 24 hours, say — and runs once for each user who crosses. When the organisation crosses a threshold runs once for the whole org and names no individual.

You also choose whose activity counts: everyone in the workspace, specific people, or the members of specific groups. That is independent of the criteria, so you can watch one team for behaviour you tolerate elsewhere.

Activity is checked every few minutes, so expect five to ten minutes between an event and the action running. Counting starts when you enable the action — it will not fire on activity that already happened.

Steps

Step	What it does
Create report	Builds a report from one of your templates, over a rolling window. Can be scoped to just the person the run is about.
Send email	Sends a templated message, optionally attaching an earlier step's report as a PDF.
Send webhook	POSTs a templated payload to an HTTPS endpoint.
Send to destination	Posts a signed message to a saved Slack, Teams or webhook destination.
Change user groups	Adds or removes the person this run is about from groups, optionally for a fixed period.
Record audit event	Writes a note to the organisation activity trail.

Any text field accepts variables. Type / to insert one: the organisation name, the run date, values from an upstream report, and — when the trigger names a person — that user's name and email. Dropping the full report variable into an email body makes the report the message.

Changing groups automatically

Group membership is what decides which policy applies to someone, so a step that moves a user between groups is changing what the extension blocks for them. Treat it accordingly.

Two things make this safe to run unattended. A group change can be time-boxed — added for 30 days, then reverted automatically — so a rule that fires wrongly heals itself rather than leaving someone under stricter enforcement indefinitely. And every change is written to the activity trail with the reason you configured, so "why am I in this group?" has an answer months later.

A step that acts on a person needs a trigger that names one. Pair it with a per-event or per-user matching trigger; the console will refuse to save it against a schedule.

Testing before you arm it

Use Test run rather than Run now. A test run evaluates the whole pipeline against your real data and shows what would happen, but sends nothing, changes no group memberships and calls no endpoints. It also surfaces variables that did not resolve, which would otherwise reach a recipient as literal braces.

Run now is a real run. It sends real email to real people.

When writing matching criteria, use Check recent matches to count events over the last seven days before saving. A trigger that has matched nothing all week is almost always a mistake in the criteria rather than a quiet period.

Warning: A test run proves the plan is coherent, not that delivery works. Because nothing leaves the system, it cannot tell you that a mailbox rejects your sender or that a webhook endpoint is unreachable. Verify delivery with a low-stakes real run before relying on an action for anything time-critical.

Destinations

Slack, Teams and webhook endpoints are saved once under Actions, then referenced by name from any action. Keeping them in one place means a signing secret can be rotated without editing every action that uses it, and a leaked URL can be revoked in one move.

Every request carries an X-Airentect-Signature header: an HMAC of the timestamp and body, using a secret only you and Airentect hold. Verify it on receipt and reject anything whose timestamp is more than five minutes old — that combination is what stops a captured request being replayed against you. Secrets are stored encrypted and are never shown again after you save them.

When an action fails

Every run is recorded with its per-step outcome. A step that fails stops the run by default, and the remaining steps are marked skipped rather than half-executed.

Failures that a retry could fix — a network blip, a rate-limited endpoint — are retried with a growing delay. Failures that a retry cannot fix, such as a deleted report template or an empty recipient list, fail once and stop. Pausing an action also stops deliveries that were already queued, so turning something off takes effect immediately rather than after the work in flight drains.