> ## Documentation Index
> Fetch the complete documentation index at: https://withforerunner.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Building automations
> Configure triggers, actions, conditions, and variables in the builder
The builder is a full-page canvas where you lay an automation out as a flowchart: a trigger at the top, actions beneath it, and conditions wherever the process needs to branch.
## Starting an automation
Select "Automations" in the sidebar.
Select "+ Add" to open the builder on an empty canvas.
Choose "When a record is created" or "When a record is updated." A configuration panel opens on the right.
Choose a category, then the record type within it, such as Code Case, Building Permit, or Grant Application. The automation runs only on records of that type.
Select the "+" beneath the trigger to open the palette, which is grouped into actions and conditions.
## Adding actions
Each action opens its own configuration panel on the right. Most fields accept [variables](#making-an-automation-dynamic-with-variables) so the values come from the record that triggered the run.
### Create a task
Set the task name, description, status, priority, assignee, and due date.
A task can also be linked to a specific property or object, chosen when you configure the action, so the work hangs off the right asset. Every task that automation creates links to that same property or object.
### Send an email
Set the subject, message body, recipient, and CC.
Recipients are one of three things:
* The record's submitter
* A specific Forerunner user in your account
* A user field on the record, which sends to whoever is selected in that field when the automation runs, and to each person if the field holds several
That last option is how a process reaches the people it routes work to, such as an assigned evaluator, contractor, or reviewer, without naming them in the automation.
Emails are plain text, and the button in the email always links back to the record that triggered it.
### Update a property warning
Adds or clears a warning on a property when the automation fires, so a warning goes up or comes down on its own. Staff can still add and clear warnings by hand.
## Branching with conditions
Conditions sit in the same palette as actions, under the Condition heading. They let one automation take different paths instead of running the same way every time. Each path shows its condition on the canvas, so you can read the logic without opening a configuration panel. Conditions can nest, and any path can end in any action.
| Condition | Behavior |
| ---------- | ------------------------------------------------------------------------------------------------- |
| Multi-path | Routes to different paths based on a value. Every matching path runs. |
| If | Splits into two paths based on a condition. One path runs when it's met, the other when it isn't. |
### Choosing between Multi-path and If
The question to ask is whether the work goes down one path, or could go down several at once.
Use **If** when there are two outcomes and only one should happen. Environmental complaints need an inspection within three days and everything else gets ten: one path or the other, never both.
Use **Multi-path** when the same field should send work to different places. Routing complaints by type is the common case, where building complaints create a task for the building inspector, zoning complaints for the zoning officer, and environmental complaints for the environmental specialist. Because every matching path runs, a case tagged with more than one type creates a task for each team at once, which an If can't do.
## Making an automation dynamic with variables
Variables are how one automation handles every record without hardcoding values. Select "Add variable" inside a field to open the picker, then select a variable to insert it as a pill. At run time, the pill is replaced with the value from the record that triggered the automation.
The picker is scoped to what the field can accept. A text field offers the record's data, while an assignee field offers ways to resolve a person.
Variables are scoped to the record type the automation runs on, organized by category, and ordered to match the form layout your team already knows. Any field you can view is available, including fields populated by an integration that nobody fills in by hand.
Examples of what you can pull in:
* Submitter details such as email, first name, or last name
* Record details such as created date, plus the record type's own fields
* Object details such as street address, parcel value, or improvement value
* Parcel details such as FIRM
Submitter variables need the submitter to have a Forerunner account. If the record type allows guest submissions, submitter variables are disabled in the picker so an automation can't be configured to silently fail. To use them, the record type has to require sign-in.
## Routing work to the right person
An assignee doesn't have to be a named person. Two variables resolve who gets the work when the automation runs, so the same automation assigns a different person per record and needs no rebuild when responsibility changes hands.
| Variable | Resolves to |
| ----------------- | ------------------------------------------------------------------------------------------------ |
| Submitter | Whoever filed the record |
| Intersecting maps | The user responsible for a [map](/docs/maps/overview) that intersects the record's property or object |
Map-based routing depends on your account having those maps loaded and users associated with them. Set that up before building the automation.
## Publishing
A new automation stays a Draft until you publish it. Publishing sets it Live, and it starts running on record events from that point forward. Publishing doesn't act on records that already exist.
To stop a Live automation without losing its configuration, set it to Paused.
## Tips
Publish a simple version, confirm it runs the way you expect on a real record, then go back and add conditions. It's easier to tell what went wrong with one path than with five.
If the person who should get the email is selected on the record, target that field rather than a specific user. The automation then reaches the right contractor or evaluator without an edit for each one.
An import that creates records fires any Live "record is created" automation once per record. Pause first if you don't want that, and publish again afterward.
The Automations page lists every automation in the account. A name like "Failed inspection creates crew follow-up" is easier to maintain than "Inspection automation 2."