Not every trigger should run every action. Sometimes you only want to send an email if the user has a specific role. Sometimes you want to notify one Slack channel for high-value orders and a different one for everything else.

Condition nodes let you add that logic. They test a value from the trigger data and split your workflow into two paths: a Yes branch and a No branch.

What a condition node does #

A condition node sits between your trigger and your actions on the canvas. It evaluates a single test, then routes the workflow down the matching branch.

Actions on the Yes branch run only when the condition is true. Actions on the No branch run only when it’s false. You can leave either branch empty if you only need to act on one outcome.

The condition uses the same data the trigger collected, so you can test against any field the trigger exposes: a user’s role, a post’s category, an order total, a comment’s content, or any other value from the triggering event.

Adding a condition to your workflow #

Open your workflow on the canvas. Click the + button below the trigger node (or any action node) and select Condition from the node type list.

The condition configuration panel opens on the right. Set three things:

Field: The piece of trigger data you want to test. For a user trigger, this might be roles or user_email. For a post trigger, this might be categories or post_type. For a WooCommerce trigger, this might be order.total.

Operator: The comparison to run. See the full list below.

Value: The value to compare against. This is a plain text field and does not support merge tags — enter the literal value you want to match.

Once saved, the condition node shows two output connectors on the canvas: one for Yes and one for No. Connect your action nodes to whichever branches you need.

Available operators #

Operator	How it works
equals	True when the field value exactly matches your value
not equals	True when the field value does not match your value
contains	True when the field value includes your value as a substring
does not contain	True when the field value does not include your value
greater than	True when the field value is numerically greater than your value
less than	True when the field value is numerically less than your value
is empty	True when the field value is empty, null, or not set
is not empty	True when the field value has any non-empty value

Use greater than and less than for numeric comparisons like order totals, post IDs, or user meta values stored as numbers.

Use contains and does not contain for arrays (like roles or categories) and for partial text matches in string fields.

What fields you can test #

The fields available in a condition depend on which trigger your workflow uses.

Trigger category	Condition fields
User triggers	User role, email address, user meta values
Post triggers	Post type, post status, category, author
Comment triggers	Comment content, author name, author IP, approval status
Custom	Any raw field from the trigger data

The Custom option lets you enter any field name directly. This is useful for testing fields that aren’t listed in the standard condition UI, including fields from Pro triggers or data passed in via merge tags from earlier steps.

Practical examples #

Send a different welcome email based on user role

Trigger: User Registered Condition: roles contains customer Yes branch: Send Email (customer welcome) No branch: Send Email (general welcome)

Only notify the team for high-value orders

Trigger: WooCommerce Order Created Condition: order.total greater than 200 Yes branch: Send Slack notification No branch: (empty, no action)

Auto-approve comments from registered users

Trigger: Comment Submitted Condition: user_id is not empty Yes branch: Update Comment Status to approved No branch: (empty, leave comment pending)

Flag posts in a specific category for editorial review

Trigger: Post Published Condition: categories contains sponsored Yes branch: Add Post Meta (review_required, true) and send admin email No branch: (empty, no action)

Chaining multiple conditions #

You can add more than one condition node to the same workflow. Each condition node connects to the next part of the workflow on its Yes or No branch.

For example, you might first test whether the order total is above a threshold, and then on the Yes branch test whether the customer is in a specific country. The second condition sits on the Yes branch of the first, creating a two-level check.

There’s no set limit on how many condition nodes you can chain, but keep workflows readable. If you find yourself nesting more than three or four levels deep, consider whether the logic belongs in separate workflows triggered by more specific events.

Conditions vs trigger filters #

Conditions are evaluated after the trigger fires. The workflow runs, reaches the condition node, evaluates the test, and takes the matching branch.

This is different from a workflow that simply doesn’t run at all. Both approaches have their place.

Use a condition node when you want different actions to happen for different outcomes from the same trigger. Both paths are part of the automation.

Use run control and specific triggers when you want the workflow to only start in very narrow circumstances. For example, using the Post Status Changed trigger instead of Post Published gives you access to both old and new status fields, letting you build a condition like “only act when the new status is publish and the old status was pending.”

Debugging conditions #

If a workflow runs but takes an unexpected branch, check the execution log.

Go to Krom Automation > Logs, find the execution, and click into it. Each step shows its input data and its outcome. The condition node shows what value was tested, what the operator was, and which branch it took.

This makes it straightforward to see whether a condition evaluated to Yes or No and why.