Step conditions
Run a workflow step only when its conditions are met. Build rules on the payload, subscriber and context in the visual editor, and see how skips behave.
A step condition is a rule attached to one step of a workflow. When the workflow reaches that step, Notifly evaluates the rule: if it is true the step runs, and if it is false the step is skipped and the workflow moves on. A step with no conditions always runs.
Use conditions to send a push only to subscribers on a certain plan, an SMS only when an amount passes a threshold, or an email only when the payload has a field set.
Add conditions to a step
- Open a workflow in the dashboard's editor and select a step.
- In the step's side panel, choose Step conditions. The row shows how many conditions the step has.
- In the Step conditions for editor, choose Add condition, pick a field, an operator and a value. Choose Add group to nest conditions, and switch a group between AND and OR.
The editor saves as you work. A group holds up to 10 conditions by default.
Step conditions are available on the channel steps (email, SMS, push, chat, in-app) and on the digest, delay and throttle steps. They are edited in the Development environment; other environments show them read-only and receive changes when you publish.
What a condition can test
The field picker offers the data the workflow has when the step runs:
| Field | Meaning |
|---|---|
payload.<name> | A value from the payload of the trigger request. Fields from the workflow's payload schema are suggested. |
subscriber.<name> | An attribute of the recipient, including your own custom subscriber.data.<name> fields. See Subscribers. |
context.<type>.id and context.<type>.data.<name> | The context sent with the trigger. |
Operators depend on the type of the field:
| Type | Operators |
|---|---|
| Text | equals, does not equal, is empty, is not empty, contains, begins with, ends with, and their negations, in, not in |
| Number | equals, does not equal, less than, less than or equal to, greater than, greater than or equal to, between, not between |
| Boolean | is, is not |
| Date | on, not on, before, on or before, after, on or after, between, not between, more than X ago, less than X ago, within last, not within last, exactly X ago |
| Date and time | at, not at, before, at or before, after, at or after, between, not between, plus the same "X ago" operators |
| List | contains, does not contain, contains any of, does not contain any of |
Every type also offers is null and is not null.
What happens when a step is skipped
When the conditions are not met, the step does not run and the activity feed records "Step was skipped based on steps conditions". Each step is evaluated on its own conditions, so a skipped email step does not stop a following SMS step from running.
Conditions as JSON Logic
Conditions are stored on the step as a JSON Logic rule in the step's skip control value, which you can read and write through the workflows API. The rule uses the same field names as the editor:
{
"and": [
{ "==": [{ "var": "payload.tier" }, "pro"] },
{ "==": [{ "var": "subscriber.data.role" }, "admin"] },
{ ">": [{ "var": "payload.amount" }, "4"] }
]
}Despite its name, a skip rule that evaluates to true lets the step run, and one that evaluates to false skips it. This is the same behavior the dashboard editor shows: the conditions describe when the step should execute.
Email layouts
Wrap every email in one reusable layout for your header, footer and styling. Add the content variable, pick a layout per step and override it per trigger.
Payload schema validation
Describe the payload a workflow expects as a JSON Schema, reject bad trigger requests with a 400 before anything is queued, and apply defaults to gaps.