Conditions

Conditions act as guards or filters in an ECA model. They determine whether a particular path of actions should be executed. If a condition evaluates to TRUE, the connected actions proceed; if FALSE, that branch is skipped.

What is a condition?

A condition is a yes-or-no check applied to a connection between components in your model. It answers the question: "Should this path be followed?"

Conditions do not perform any changes themselves -- they only evaluate a situation and return TRUE or FALSE. This makes them safe to use: a condition never modifies data.

Common condition types

ECA offers a wide range of conditions. Some of the most frequently used include:

Scalar comparison

Compare two values (equal, not equal, greater than, less than, contains, etc.). Useful for checking field values, token contents, or any text/number comparison.

Entity type and bundle

Check whether an entity is of a specific type (e.g. node, user) or bundle (e.g. article, page). Essential when an event applies to multiple content types but you only want to act on one.

User role

Verify whether the current user has a specific role. Commonly used to restrict actions to administrators or specific user groups.

Entity field value

Check whether a specific field on an entity has a particular value, is empty, or matches a pattern.

Route match

Evaluate the current Drupal route or path, useful for request/response event models.

Browsing available conditions

The full list of conditions depends on which modules are installed. See the Plugins section for a complete reference, organized by module.

Negating conditions

Every condition in ECA can be negated. When you negate a condition, the logic is inverted: a condition that would normally return TRUE returns FALSE instead, and vice versa.

This is useful when you want to express "if NOT this condition" without needing a separate condition plugin. For example, negating a "user has role" condition effectively becomes "user does NOT have role".

Combining conditions (AND / OR logic)

A connection carries at most one condition. There is no way to put a second condition on the same connection: in the stored configuration, a successor link references exactly one condition by ID. Combining conditions therefore means arranging one connection per condition.

AND logic

Chain the conditions through a pass-through action. ECA ships the Chain action for AND condition action (plugin ID eca_void_and_condition) for exactly this purpose. The action does nothing itself. Its only job is to give you a second connection to put the next condition on:

Event  --[Condition A]-->  AND  --[Condition B]-->  Action

ECA evaluates each connection in turn, so Action runs only when both conditions return TRUE. Add another chain action for every further condition.

OR logic

Draw a separate connection from the same source to the same target and put one condition on each. If any of those conditions returns TRUE, the target runs:

       --[Condition A]-->
Event                      Action
       --[Condition B]-->

OR paths are inclusive

ECA evaluates every outgoing connection and does not stop at the first match. If both conditions return TRUE, the target action runs twice, once per connection. Negate one of the conditions if the target must run at most once.

Both patterns are shown together in the Combined Conditions library model, which also nests them to express (C5 or C6) and (C7 or C8).

Gateways do not add branching logic of their own. They are useful for merging or splitting the visual flow, not for expressing conditional logic.

Adding conditions to a model

Conditions are not standalone components that sit on the canvas on their own. Instead, they are attached to the connections (edges) between events, actions, and gateways. This is an important distinction that newcomers often find surprising.

Workflow Modeler

1. First, ensure you have an event and at least one action connected by an edge.
2. Click on the edge (the line connecting two components).
3. In the side panel, add a condition by selecting from the available condition types.
4. Configure the condition's settings (comparison values, fields to check, etc.).
5. Optionally enable Negate to invert the condition logic.

You can also use the Quick-Add feature: when adding a successor from a node, the popup allows you to insert a condition on the new edge directly.

BPMN.iO

1. Draw a sequence flow (arrow) from an event or action to the next element.
2. Click on the sequence flow arrow.
3. In the configuration panel on the right, select a condition from the dropdown.
4. Configure the condition's settings.
5. Optionally enable negation.

Note

In BPMN terminology, a condition on a sequence flow is called a "conditional flow". The condition determines whether the flow is followed.

Classic Modeler

1. When connecting components, the form interface provides a field for adding conditions.
2. Select the condition type and configure its parameters.
3. Use the negate option if needed.

Tips for working with conditions

• Conditions go on connections, not nodes: This is the most common point of confusion for new users. You do not add a condition as a separate box on the canvas. Instead, you attach it to the arrow/edge between two components.
• Keep conditions simple: If a condition requires complex logic, consider breaking it into multiple simpler conditions or using custom events to separate concerns.
• Use negation wisely: Rather than creating a separate "is not" condition, negate the existing one.
• Test conditions with debugging: Use the debugging tools to verify that conditions evaluate as expected. The logs show which conditions passed and which were skipped.
• Mind token availability: Conditions often reference tokens. Ensure the token you are checking has been made available by the event or a preceding action. See Tokens.
• Know the stored shape: If you write or review models as configuration, see Authoring models as configuration for how conditions are stored in a keyed pool and referenced from successor links.