Starting an automation
1
Open the Automations page
Select “Automations” in the sidebar.
2
Add an automation
Select ”+ Add” to open the builder on an empty canvas.
3
Select a trigger
Choose “When a record is created” or “When a record is updated.” A configuration panel opens on the right.
4
Pick the record type
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.
5
Add what happens next
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 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
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.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.
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
Build the trigger and one action first, then add branches
Build the trigger and one action first, then add branches
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.
Use a user field instead of a named recipient when the person changes per record
Use a user field instead of a named recipient when the person changes per record
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.
Set the automation to Draft or Paused before a bulk import
Set the automation to Draft or Paused before a bulk import
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.
Give automations names your whole team can read
Give automations names your whole team can read
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.”