A condition in automation is a logical test evaluated during a workflow run that returns true or false and thereby decides whether a step executes, which branch the process follows or whether the run continues at all. Conditions turn a fixed sequence of steps into a process that reacts to the data it receives, which makes them one of the basic building blocks of automation fundamentals alongside triggers, actions and workflow state.
A condition always has the same anatomy: a value to inspect, an operator and a reference value, for example order total greater than 500 or customer country equals Germany. Simple conditions can be combined with logical operators into rules of almost any complexity, but every additional clause also adds a place where the workflow can behave unexpectedly.
How a condition is evaluated in a workflow
When a workflow reaches a condition, the engine resolves the referenced data, such as a field from the trigger payload, the output of an earlier action or a stored workflow variable. It then applies the operator and obtains a Boolean result. Depending on the platform, a false result either skips the following steps, stops the run or sends execution down an alternative branch.
Evaluation happens at run time, not at design time. The same workflow can therefore take different paths for every record it processes. This is also why testing a condition with one sample record is never enough: the values that break it usually appear only in production data.
Conditions appear in several places in a workflow, and each placement has a different effect, as the table shows.
| Placement | What it controls | Typical example |
|---|---|---|
| Trigger filter | Whether a run starts at all | Only new tickets with priority high |
| Gate or filter step | Whether the run continues | Stop if the email address is empty |
| Branch or router | Which path the run takes | Domestic versus international shipping |
| Loop condition | How long a repetition continues | Retry while the status is pending |
| Action precondition | Whether a single step is executed | Send SMS only if a phone number exists |
Operators, data types and compound logic
The operator must match the data type of the inspected value. Comparing a number stored as text, or a date in an unexpected format, is the most frequent source of conditions that silently return the wrong result.
| Data type | Typical operators | Common pitfall |
|---|---|---|
| Text | Equals, contains, starts with, matches pattern | Case sensitivity and trailing spaces |
| Number | Equal, greater than, less than, between | Numbers stored as text compare alphabetically |
| Date and time | Before, after, within the last n days | Time zones and date formats |
| Boolean | Is true, is false | Empty value treated as false |
| List or array | Contains, is empty, length | Checking one item instead of all |
| Existence | Exists, is empty, is null | Empty string differs from missing field |
Simple conditions are combined with AND, OR and NOT. AND requires every clause to be true, OR requires at least one, and NOT inverts a result. Mixing AND and OR without explicit grouping is risky because platforms differ in operator precedence, so complex rules should always be grouped visibly, for example (A AND B) OR C.
Condition compared with trigger, action and workflow state
Conditions are easiest to understand next to the other basic elements of a workflow. A trigger starts a run, an action changes something, and workflow state records where a run stands. A condition changes nothing by itself; it only decides what happens next.
| Concept | Role in a workflow | Changes data | Example |
|---|---|---|---|
| Trigger | Starts a run when an event occurs | No | New form submission received |
| Condition | Tests data and selects the path | No | Budget field above 10,000 |
| Action | Performs work in a system | Yes | Create a record in the CRM |
| Workflow state | Stores progress and variables | Yes, internally | Approval status set to waiting |
| Error handler | Reacts to failed steps | Sometimes | Notify the owner after three retries |
The boundary between trigger and condition matters for cost and load. A trigger filter prevents unnecessary runs entirely, whereas a condition placed after the trigger still consumes a run or task credit on many platforms. Filtering as early as possible is therefore a standard optimization.
Designing conditions that stay reliable
Well-designed conditions are explicit, testable and complete. Every branch should have a defined outcome, including the case in which none of the expected values occurs.
| Situation | Recommended practice | Reason |
|---|---|---|
| Several mutually exclusive cases | Use a router with a default branch | Unexpected values still have a path |
| Values from external systems | Normalize case, trim spaces, convert types first | Prevents false mismatches |
| Rules used in many workflows | Store thresholds as shared variables | One change updates every workflow |
| Complex business rules | Move logic to a decision table or code step | Keeps the visual workflow readable |
| Data that may be missing | Test for existence before comparing | Avoids errors on null values |
Teams should also log the evaluated values of important conditions. When a customer asks why an order was not processed, the log shows immediately which clause returned false and with which data.
Common mistakes with conditions
- Missing else branch. Records that match no rule are silently dropped.
- Overlapping branches. Two rules can both be true, and the platform then takes only the first match.
- Hard-coded values. Thresholds buried in many workflows drift apart when policy changes.
- Type mismatches. The text 9 is greater than the text 10 in alphabetical comparison.
- Deeply nested logic. Five levels of branches become impossible to test and review.
A useful review habit is to write down, for every condition, one example that should pass and one that should fail, and to run both through the workflow before activating it.
Understanding it simply
A condition is an if-then question that an automated process asks itself. If the package weighs more than 20 kilograms, use the freight carrier; otherwise, use the regular courier.
The process checks the facts and then picks the right path, exactly as a person would follow a simple office rule. Good conditions are clear, cover every possible case and are written so that someone else can read them and understand the decision.
Applied in practice
A small accounting firm automates how incoming invoices are handled. A trigger fires whenever an invoice arrives in a shared mailbox, and an extraction step reads the supplier, amount and due date.
Three conditions then decide the route. Invoices from known suppliers below 1,000 euros go straight to the payment queue. Invoices above that amount go to a partner for approval, and invoices from unknown suppliers go to a review list. A default branch catches anything the extraction could not read, such as a missing amount. After the change, routine invoices are processed the same day, and no invoice disappears unnoticed, because every record ends up in one of the four defined paths.