> ## 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," "When a record is updated," or "On a recurring schedule." A configuration panel opens on the right.
For a record trigger, 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.
For a recurring schedule, set the cadence. See [scheduling an automation](#scheduling-an-automation).
Select the "+" beneath the trigger to open the palette, which is grouped into actions and conditions.
## Scheduling an automation
Choose "On a recurring schedule" when work should happen on a cadence rather than in response to a record. Quarterly compliance reminders, monthly reporting tasks, and weekly follow-up sweeps all fit this shape.
The configuration panel sets when the automation runs:
| Setting | What it controls |
| ------------ | ----------------------------------------------------------------------------------------------- |
| Frequency | Daily, Weekly, Bi-weekly, Monthly, or Custom |
| Days of week | Which days a weekly cadence fires on |
| On | For a monthly cadence, either specific dates or a weekday position such as "the second Tuesday" |
| Start date | The date the cadence counts from. Appears when the cadence skips periods, such as bi-weekly |
| Time | The time of day the automation runs |
| Time zone | The time zone that time is read in |
| Ends | Never, on a specific date, or after a set number of runs |
Select "Custom…" under Frequency to set any interval, such as every 3 days or every 2 months.
The canvas shows the schedule in plain language, so you can read the cadence without opening the panel: "Runs every 2 weeks on Monday at 8:00 AM ET."
A monthly schedule set to a date that a shorter month doesn't have runs on that month's last day instead. The 31st becomes the 30th in April and the 28th in February.
Because nothing triggers a scheduled run, its actions name what they act on. A task action asks which record type and object to link the task to, rather than linking to a triggering record. Record and submitter variables aren't available.
## 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.
If the warning is already in the state the action would set, the step succeeds as a no-op and the automation keeps going. That's what lets one automation move a property along a warning ladder: clear the previous warning, apply the next, and the run completes whether or not someone already cleared it manually.
## 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. |
Leaving one side of an If empty is a valid setup. Use it when something should happen in one case and nothing in the other.
Conditions can read a property's warnings the same way they read field values, so an automation can branch on whether a warning currently applies before deciding what to do next. A multi-select field is offered as its own condition field, with only the operators that apply to it.
### 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
* Warnings on the property or object, each reading whether that warning currently applies
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.
Publishing a scheduled automation starts its cadence. The first run lands at the next time the schedule comes due.
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."