Building automations

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

​

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: 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.” 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 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 can be:

• The record’s submitter
• A specific Forerunner user in your account, including public website users
• 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 links back to the record that triggered it. The button says View record unless you change it under Button text.

​

Update a warning

Adds or clears a warning on the property or object 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.

​

Update a workflow

Sets the status of a workflow step, such as marking a review step complete. This action only shows up when the record type is part of a workflow.

​

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. 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

​

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.

​

Copying and sharing workflow steps

Some processes hand the same step to several people. A grant program might send one bid sheet to each contractor the homeowner picked, with each contractor seeing only their own. Two actions handle this: Copy a workflow step makes one copy of a step per person, and Share a workflow step gives a public user access to a step. Both actions show up only when the record type is part of a workflow, and both need a record trigger.

​

Copy a workflow step

How copies are made:

• Only public users get a copy. Staff selected in a user field are skipped.
• Someone selected in more than one field gets one copy.
• Copies start Open and appear after the original step, a few seconds after the record is saved.
• The original step stays in the workflow. With three contractors, the workflow shows four bid sheets: the original, plus one copy per contractor. Leave the original as a placeholder or delete it.
• If a person already has a copy, they don’t get another one, so a record that’s updated more than once doesn’t pile up copies.

​

Actions that run once per copy

Every action you add beneath Copy a workflow step runs once for each copy. The canvas groups these actions under For each copy. Create a task, Send an email, Update a workflow, Share a workflow step, and conditions can all go there. Inside that group, the variable picker adds a This copy section: The actions beneath also run for a person who already had a copy. To send an email only the first time, put it under an If condition on Copy is new.

​

Share a workflow step

• Recipients get view access to the step. Only public users are included, and staff are skipped.
• Under Copy a workflow step, the step is locked to the copy just made, so each person gets access to their own copy only.
• Used on its own, Share a workflow step shares every copy of the chosen step, but not the original. If the step has no copies yet, the run fails.
• New recipients get an email from your account with your message and a View Application button. People who already have access aren’t emailed again.
• Sharing only adds access. It never removes anyone.
• The record type has to let public users view its records, or the automation won’t save.

​

Example: sending bid sheets to contractors

1. Trigger: When a record is updated, on the Contractor Selection record type.
2. If: the approval field is Approved.
3. Copy a workflow step: copy Bid Sheet for the Contractor 1, Contractor 2, and Contractor 3 fields, named “Bid Sheet: ” followed by the Person’s full name variable.
4. Beneath it, Share a workflow step: share with This copy’s user, with a message asking them to submit their bid.

There’s no need to add an Update a workflow action to open each copy. Copies already start Open.

​

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