Understanding automations

What it is

An automation is a directed graph of decision points and actions that runs when a specific event happens in your account. You define the trigger (e.g., "when a task's status changes"), and the automation walks through the graph — evaluating conditions, taking actions, and pausing at time nodes — in a single execution path.

Every automation has a status: Draft, Published, or Deprecated. Only automations with a Published status fire when their trigger matches. You build the automation in draft, then click Publish to activate it.

Why it matters

Without automations, you'd manually create tasks, send emails, and monitor expiration dates. Automations let you encode business logic once — conditional task creation, link generation, reminders, compliance workflows — and have it run consistently every time the trigger fires.

Understanding the node structure and rerun behavior is essential before building one. The wrong trigger property or rerun setting can cause automations to fire too often or not at all.

How it works

The trigger node (Start node)

Every automation begins with a Start node. The Start node picks two things: which entity to listen to, and which property change triggers the automation.

You can listen to either Task or Placement. For Task, the watchable properties are Status, Next Action, Due Date, and Expiration Date. For Placement, it's Status. You can also trigger the automation whenever the entity is created — toggle Fire on create for that.

Picking the right property matters. If you want to react to a task moving to "Completed" status, choose Status. If you choose the wrong property — say, Due Date — the automation fires every time someone edits the due date, not when completion happens. See the how-to article for the gotchas and how to test before publishing.

The condition node

A condition node is an optional fork in the graph. You write a rule using the same Rule Builder as policies. If the rule is true, execution takes one path; if false, it takes another. A condition node has exactly two outlets — one for truthy, one for falsy.

Conditions let you send different emails to different people, or create a task only if a placement is in a certain state. Chain multiple conditions if you need a complex decision tree.

The action node

An action node does something — sends an email, creates a task, generates a link. Seven actions exist:

• Send Email

• HTTP Request

• Create Task

• Create Compliance Requirement

• Assign Task

• Create Onboarding Link

• Set Task Expiration

Set Task Expiration is gated by a feature flag and may not be available in all accounts. Reach out to support@onboarded.com if you need access.

Actions are where the automation gets work done. The output of one action (e.g., the link created by Create Onboarding Link) can become a variable that a later action uses — so a single automation might create a task, then send an email with a link to that task's form.

The reference article covers what each action does and what parameters it accepts.

The time node

A time node pauses execution. When the automation reaches it, execution stops and waits until the time condition is met. Three time baselines exist:

• Now — an offset from right now. "Wait 2 hours from this moment."

• Task expiration — an offset from a task's expiration date. "Wait 3 days before the task expires."

• Task due date — an offset from a task's due date. "Wait 1 day before the task is due."

When the timer fires, execution resumes. By default, the automation uses the same facts (employee data, placement data) it had when it paused. If you toggle Recalculate facts, the automation re-evaluates conditions and fact-based action parameters when the timer fires. This matters when the world might change during the wait — e.g., if you're checking whether a placement has moved to a new state, re-calculating picks up that change.

Publishing and reruns

When you're ready to activate an automation, click Publish. The status changes to Published and the automation runs on every trigger match. Field changes auto-save as you go — there's no separate save action.

After publishing, you can keep editing the automation. Your edits auto-save while the live configuration continues to run on every trigger match. Click Publish again to apply your changes, or Discard Changes to revert to the live state.

Rerun behavior controls what happens when the trigger fires multiple times. Choose one:

• Allow reruns — every trigger fires the automation independently. If the trigger fires twice, the automation runs twice, even if the first run is still in progress.

• Do not allow reruns — the trigger only fires the automation if no other execution is currently active. Subsequent triggers are ignored.

• Allow reruns and cancel previous runs — a new trigger cancels any in-progress execution and starts fresh. Useful when you want the latest state to always win.

Example

Take an account that needs to send a compliance task reminder 3 days before the task expires. They set up an automation with a Task Expiration trigger, then add a time node that waits 3 days before the expiration, and an action that sends an email. When the time fires, the email goes out.

A more complex example: listen for any task status change to "Pending Completion", check via condition whether the placement is in a certain state, and if so, create a follow-up task and send an email with a link to it. If the condition is false, skip both. This flows in sequence because each action's output can feed the next.

Read next

• 📄 How do I build an automation?

• 📄 Automation triggers and actions reference