Skip to content
memberarea memberarea.io

Conditions, branches and delays

Check rules, split and join paths, wait for a while or until a date, work with the data, repeat steps for a list, call another automation and answer a webhook.

In this article

Triggers start an automation and actions do the work. The steps in this article decide what happens in between: which path a member takes, when the next step runs, and what data the following steps get to work with.

Open Automations

Where you find these steps

In the editor, open the library and switch to the Actions tab. The steps from this article sit at the top in their own section, called Control. Drag one onto the canvas or click it, then connect it like any other step.

The Actions tab of the library with the Control section listing condition, delay, split, merge, loop and the other flow steps.
The Actions tab of the library with the Control section listing condition, delay, split, merge, loop and the other flow steps.

A few rules apply to every step:

  • The input sits on the left and the exits sit on the right. Steps with more than one exit label each exit, for example Yes and No.
  • Each input takes one connection. If you draw a second line into the same input, it replaces the first one. To bring two paths together, use Merge.
  • A line cannot lead back to an earlier step. The editor does not let you draw it. To repeat steps, use Loop.
  • An exit with nothing connected simply ends that path.

Click a step to open its settings on the right. Fields marked with a star are required. When a step's setup has a problem, the editor marks it with a yellow warning.

Building an automation

Checking rules: Condition, Filter and Compare

How rules work

Condition and Filter check a list of rules. Each rule has a key, an operator and a value. Add rule adds one, and the cross next to the key removes it.

The key says what to look at:

  • A field from the data the automation carries, for example email or a field the trigger delivers.
  • member. followed by a member field, for example member.email or member.first_name.
  • member.cf_ followed by the ID of a custom field. It reads the value as it is stored: for a choice field that is the option's value, not its label, and a date field gives the stored date. A field without a value counts as empty.
  • member.tags or member.groups. The operators change to has and has not, and you pick the tag or group from a list.
  • An email engagement value, for example email.opened_automation (1 when the member opened an email from this automation, otherwise 0), email.opened_this_step (an email from the nearest email step before this one), email.opened_ever, email.opened_days_ago or email.opens_7d. The same values exist for clicks, for example email.clicks_30d.

The key field suggests these as you type, including your custom fields by name. Picking one fills in member.cf_ and the ID, and below the rule a hint names the field, for example "Custom field: Plan".

The operators are equals, does not equal, contains, does not contain, in (comma list), not in (comma list), is empty, is not empty and the number comparisons >, ≥, < and ≤. Keep in mind:

  • equals compares the values as text.
  • contains looks for the value inside the text and respects upper and lower case.
  • in (comma list) takes several values separated by commas, for example gold, silver, and passes when the key matches one of them.
  • The number comparisons only pass when both sides are numbers.

Match decides how the rules add up: All rules must pass or Any rule passes.

A Condition step with two rules on email opens and clicks, the Match setting and the Yes and No exits on the canvas.
A Condition step with two rules on email opens and clicks, the Match setting and the Yes and No exits on the canvas.

Condition

Condition sends the member down one of two exits, Yes when the rules pass and No when they do not. Without any rules, every run takes the Yes exit, and the step shows Always yes.

Use it for real either/or decisions, for example a welcome email for new customers and a different one for returning customers.

Filter

Filter has a single exit. Under Keep when you set the rules, and Match works as above. When the rules pass, the path continues. When they fail, the path stops at this step and the step counts as skipped in the run. Without rules, everything passes.

Use Filter when only one outcome matters, for example "continue only for members in the group Premium".

Compare

Compare checks exactly two values against each other:

  • First value (required) and Second value each take a field name from the data, member. plus a member field, member.cf_ plus the ID of a custom field, an email value such as email.opens_7d, a placeholder like {{score}}, or a fixed value such as 10. This field makes no suggestions. The ID of a custom field is the one in its placeholder {cf_…}, see Triggers and actions.
  • Operator offers equals, does not equal, contains, greater than, greater or equal, less than and less or equal.

The exits are Match and No match.

Splitting and joining paths: Split and Merge

Split

Split fans the flow out into several paths. Number of branches sets between 2 and 5 exits, labelled Path 1, Path 2 and so on. Every path gets the same data and runs on its own. A delay on one path holds only that path.

Merge

Merge brings paths back together. Number of incoming paths sets between 2 and 5 inputs. Continue when decides how it behaves:

  • Each path continues on its own is the default. Every path that arrives continues through the steps after Merge by itself, so those steps run once for each path.
  • Every path has arrived waits until a path has arrived on every connected input, then continues once. The data of all paths is combined. When two paths carry the same field, the path that arrived last wins. The wait also covers paths that contain a Delay or Wait until date.

If a path never arrives, for example because a Filter stopped it or a Condition sent the member elsewhere, Merge continues with the paths that did arrive as soon as nothing else in the run is still running or waiting.

Waiting: Delay and Wait until date

Delay

Delay pauses the path for a fixed time. Set Duration (at least 1) and Unit: Minutes, Hours or Days. A new Delay starts at 1 hour. If the duration is empty, the editor warns "Delay has no duration."

Wait until date

Wait until date pauses until a date that comes from the data:

  • Date field (required) names the field that holds the date, for example renewal_date. For a member field, put member. in front of its name. For a custom date field, write member.cf_ and the field's ID.
  • Offset direction, Offset and Unit move the moment. After the date (+) waits longer, Before the date (-) continues earlier. Three days before a renewal, for example, is Before the date (-) with 3 Days.

If the moment has already passed, the path continues at once. If the field is empty or holds something that is not a date, the path continues without waiting, and the step shows a note in the run, for example "No date found in "renewal_date". The flow continued without waiting." A date without a time zone is read in the time zone set for your platform.

What happens during a pause

A Delay or Wait until date does not keep anything busy. The run stores where it stopped, and a background job picks it up again when the time is due. While it waits, the run history shows it as Waiting with the date and time under Resumes. When you open the run and click the waiting step, the Run tab shows the same.

A run paused at a Delay step, with the step marked as waiting and the Run tab showing when the run resumes.
A run paused at a Delay step, with the step marked as waiting and the Run tab showing when the run resumes.

A waiting run continues with the version it started with, even if you publish a new version in the meantime. If you archive or delete the automation, waiting runs are cancelled when their time comes. Pausing the automation cancels them too, except test runs you started by hand.

Testing and run history

Working with the data

Every run carries data: what the trigger delivered plus whatever earlier steps added. The next three steps change that data. Later steps can use each field as a placeholder, for example {{discount_code}}.

Set fields

Set fields adds fields or overwrites existing ones. Under Fields to set, each row has a key and a value. Add row adds another row. Values can contain placeholders, for example Hello {{member.first_name}}.

Date & Time

Date & Time calculates a date and stores it in a field. It does not wait. To wait for the calculated date, follow it with Wait until date.

  • Starting from: Now or A date already in the data. With the second option, Date field appears and names the field to start from: a field from the data, a member field such as member.created_at, or member.cf_ and the ID of a custom date field. If that field is empty or unreadable, the step starts from now.
  • Direction (In the future (+) or In the past (-)), Offset and Unit (Minutes, Hours, Days, Weeks or Months) move the date.
  • Format stays empty for the standard format 2026-10-22T14:30:00+02:00, or takes a pattern such as Y-m-d for 2026-10-22 or d.m.Y for 22.10.2026.

The step calculates in the time zone set for your platform, the same one Wait until date uses. The standard format ends with its offset, for example +02:00, so a following Wait until date reads the same moment.

  • Store in field (required) names the field for the result. It starts as date.

Expression

Expression calculates a value with a short formula and stores it in a field.

  • Expression (required) holds the formula. payload stands for the data and member for the member's fields, for example payload["score"] * 2 or member["first_name"] ~ " " ~ member["last_name"]. You can calculate with + - * /, compare with ==, > or <, combine with and and or, choose with condition ? a : b, and join text with ~.
  • Store result in (required) names the field for the result. It starts as result.

Sensitive member data such as the password is not available. If the formula cannot be calculated, the field stays empty and the run continues.

Repeating steps: Loop

Loop runs the steps after it once for each item in a list.

  • List field (required) names the field that holds the list, for example items, or member.tags for the member's tags.
  • Store each item as sets the field name for the current item. It starts as item. The position is stored next to it as item_index, counting from 0.

Loop has a single exit, and everything behind it runs once per item. There is no extra exit for "after the last item". If the field is empty or is not a list, the path stops at the loop.

Two limits keep runs under control. A loop handles at most 200 items and ignores the rest. And a run executes at most 500 steps before it pauses or ends. A loop over 200 items with three steps behind it would need 600 steps, so the run stops with an error. Keep loops short, or move the work into a separate automation with Run workflow.

Calling another automation: Run workflow

Run workflow starts another automation as a step and continues once it has finished.

  • Workflow (required) lists your active automations that have a published version. The automation you are editing is not in the list, because an automation cannot call itself.
  • Use the result decides what comes back: Ignore it, keep this flow data, Merge it into this flow data or Store it under a field. For the last option, Field name sets the field. If you leave it empty, the result lands in sub.

The other automation starts at its trigger with this run's data and member, whatever kind of trigger it has, and appears in its own run history. Its result is the data at its End step, or at its last completed step if it has no End. If it pauses at a Delay, this flow does not wait: it takes the data reached so far, and the other automation continues later on its own.

When something goes wrong:

  • If the other automation fails, has no published version or no longer exists, this step fails and so does the run.
  • If the other automation is paused, this flow continues without it, and the step shows a note in the run.
  • Automations can call each other up to five levels deep. Beyond that, the step fails.
  • If no workflow is selected, the path stops at this step. The editor warns about it beforehand: "Run workflow has no workflow selected."

Answering a webhook: Respond to webhook

Respond to webhook is for automations that start with the trigger Incoming webhook. It decides what the calling system gets back.

  • HTTP status offers 200 OK, 201 Created, 202 Accepted, 400 Bad Request, 404 Not Found and 500 Server Error.
  • Response body starts as { "ok": true } and can contain placeholders, for example { "ok": true, "code": "{{discount_code}}" }. A body in valid JSON goes out as JSON, anything else as plain text.

As soon as this step follows the Incoming webhook trigger in the published version, a call to that webhook no longer just starts the automation in the background. The call waits while the automation runs, and the reply goes out once the run has finished or reached its first pause. A step on a path that the webhook trigger never reaches, for example behind a different trigger, changes nothing. That is why the step only works before any Delay or Wait until date. If one of them comes first, the caller gets the standard reply {"ok": true, "triggers_fired": 1}, and the editor warns: "Respond to webhook runs after a delay or wait step. The webhook caller gets the default reply instead."

The step has no exit, so nothing follows it on its path. Other paths, for example after a Split, keep running.

Triggers and actions

Ending a path: End

End stops the path it sits on. It has no settings and no exit. Other paths of the same run keep going, and the run counts as completed once all of them are done.

A path without further connections ends on its own as well. End makes the end visible on the canvas, and it decides which data a calling automation receives from Run workflow.

Last updated on October 23, 2026

Was this article helpful?

Related articles