Automations

Automations do your routine data work for you. Each one reads like a sentence — WHEN something happens, on WHICH RECORDS, DO these actions — and everything in it is configuration: a duplicate check, a monthly rollup, a “flag members with no payment” sweep are all just automations you assemble in Admin → Automations.

Anatomy of an automation

Create one with + New automation (name + record type), then fill in the three cards of the editor:

WHEN — the trigger

An automation can fire on any combination of:

Record events — a record is created, updated, or a specific field changes.
A workflow transition — when “Approve” fires, for example.
A schedule — run it every night, every hour, at the cadence you choose.
Manually — a Run button, for on-demand maintenance.
A webhook — an external system calls a secret URL to trigger it.

An optional condition filters the triggering record — “only when amount > 100”, built with the standard filter editor.

WHICH RECORDS — the selection

Choose what the actions apply to:

The triggering record — the simple case: the record that just changed. With this selection the actions can only target that record.
A filtered query — any set of records of any type, with the full filter editor, joins to related types, and two special values to correlate with the trigger: $subject (“the triggering record”, for reference/relationship conditions — “payments belonging to the person who just changed”) and $subject.field (one of the trigger’s values — messageID = $subject.inReplyTo selects the email the trigger replies to, no reference needed). This is how you act on a different record than the one that triggered: select the other record’s type here, tie it to the trigger, and the actions then offer each matched record as their target — with {{$subject.field}} templates to carry values across.
Groups with a count — group records by one or more fields and keep only groups above a threshold. This is duplicate detection as configuration: group people by email, keep groups with more than one, and act on the duplicates.

DO — the actions

An ordered list of steps, each aimed at the triggering record, each selected record, a joined record, or (for grouped selections) the survivor/duplicates of each group:

Set fields — update values, with merge templates like {{firstName}} from the records involved.
Create a record — or update-if-exists, to maintain derived records. Later steps can reference it as {{$created.id}} / {{$created.ref}} / {{$created.<field>}} — e.g. a Set fields step back-filling a reference on the triggering record (Requestor = {{$created.id}}). Set for matched-and-skipped records too.
Create a relationship — link the record to another.
Fire a workflow transition — push records through their lifecycle.
Add a comment — post into a Comments field’s stream on the target record (rich HTML with merge values, an optional linked record, files copied from a record’s File field (e.g. the triggering email’s attachments), and comment notifications like a human comment). By default authored as “Automation” at the current time — or set As user (a template resolving to an account email, e.g. the email’s sender) and At (a template resolving to a date, e.g. the email’s date) so the comment reads exactly like the original message.
Create a user account — upsert a workspace user by email (templates for email and names), adding them to a group (which defines their access — Admin groups are refused, so an automation reacting to external input can never mint privileged access) and linking them to a record (their Person). When the email already exists you choose: fill gaps (add missing names/link, ensure the group) or skip (leave the account completely untouched). The account can’t sign in until a password is set. Either way, later steps in the same automation can reference the user as {{$user.id}} / {{$user.email}} / {{$user.firstName}} — for example a Set fields step stamping a User field on the Person with {{$user.id}}.
Delete a record — for confirmed clean-ups.
Run an integration job — hand off to the Integration hub.

Every action goes through the normal engine — validation, permissions, history, notifications — so automated changes behave exactly like human ones, and safety limits prevent automations from triggering each other forever.

Chaining automations

When one automation depends on another’s writes, chain them explicitly: give the follower the trigger “After another automation” and check the automation(s) it follows. The follower runs when the source completes, inheriting its triggering record — so “create the person, then set the thread key, then comment the thread” is three automations chained by declaration, not by luck. Cycles are blocked and chains are depth-limited by the same safety guard that stops event loops.

Run history

The automation’s run log records every execution: when it ran, how many records matched, how many were affected, and any errors — with links to sample affected records so you can inspect exactly what happened. It’s your first stop when tuning a new automation.

Before you activate

Start with the trigger narrow — one event, a tight condition.
Test the selection with a restrictive filter and check the matched count in the run log.
Run it manually a few times and follow the sample links.
Only then widen the filter and enable the schedule.

Automations are powerful precisely because they’re generic — treat a new one like a new colleague and review its first day’s work.