Control Steps

​

Overview

Control steps shape the flow of a run instead of performing work:

• Filter — stop the run unless conditions match.
• Branch — split the automation into multiple paths, each with its own rules and steps.

Both use the same condition editor described below.

​

Filter

A Filter step checks its conditions when the run reaches it. If they match, the run continues to the next step; if not, the run stops there with the status Halted. Filters can reference anything available at that point in the run — trigger fields and the outputs of earlier steps. A common pattern is a Find Lead step followed by a Filter on its Lead found? output, so the rest of the automation only runs for leads that exist in Apten.

​

Branch

A Branch step splits the automation into 2 to 5 branches. Each branch has its own Branch rules (conditions) and its own chain of steps. How branches are evaluated when a run arrives:

• Every branch whose rules match runs, one after another, in the order the branches are defined. Branches are not mutually exclusive — if a record matches two branches, both run.
• One branch can be marked as the Fallback branch. It has no rules and runs only when no other branch matched.
• If no branch matches and there is no fallback, the run stops with status Halted.
• If a step inside one branch fails, the other matching branches still run, but the run’s overall status is Failed.

A few structural rules:

• A Branch is always the last step of its chain — branches don’t merge back together, and each branch runs to its own end.
• Branches can contain their own Branch steps, nested up to 3 levels deep. Each chain (the top level, or a branch) contains at most one Branch step, always at its end.
• Each branch can hold up to 10 steps, and the Branch step itself counts as one — a chain that ends in a Branch has room for 9 other steps.

​

The Condition Editor

Conditions appear throughout Automations — trigger Conditions, the Watched field filter, Filter conditions, Branch rules, and the optional conditions on Find CRM Record — and they all work the same way. Each condition is a row of three parts:

1. Field — searchable dropdown of available fields
2. Operator — =, ≠, contains, >, <, in, not in, is set, is not set (the list adapts to the field’s type)
3. Value — a typed input matching the field: text, number, Yes/No, a picklist of the field’s options, or a date picker. in / not in accept multiple values.

With more than one condition, choose how they combine — AND (every condition must match) or OR (at least one must match). The chosen AND/OR is shown between the rows so the logic reads inline.

​

Condition groups

To mix AND and OR logic, add a group. A group is a set of conditions with its own AND/OR operator, evaluated as a single condition in the outer list. For example, Status = Qualified AND (Source = Web OR Source = Referral) is the outer list combined with AND, containing a group combined with OR.

• Click Add group in the condition editor to create one; add conditions to the group with its own Add condition button.
• A group needs at least one condition, and groups can’t contain other groups — one level of grouping keeps the logic easy to read.
• Groups work on every condition surface: trigger Conditions, Filter conditions, Branch rules, and Find CRM Record conditions. (The Watched field filter stays a single condition.)

​

Relative dates

On Filter, Branch, and Find CRM Record conditions, date fields offer two value modes:

• Specific date — a fixed date or time
• Relative to trigger — an offset from when the run fired, e.g. 3 days after trigger or 2 hours before trigger. Use > and < with relative dates, e.g. AppointmentDate < 2 days after trigger to mean “within the next 2 days.”

Trigger conditions don’t support relative dates — they use fixed values only.