Agentic Workflow Conditions
Audience: Administrators, Developers, Solution Architects
Purpose: Defines what Conditions are, explains how they evaluate criteria and route execution, and surfaces the behavioral caveats and limitations users must understand to design conditional logic that is reliable, predictable, and debuggable.
Overview
Conditions are the primary mechanism for introducing decision logic into an Agentic Workflow. Every Condition evaluates one or more criteria and routes execution down one of exactly two paths, yes or no, based on the result.
There is no neutral outcome. Understanding how Conditions evaluate, and where they can fail, is essential for designing Agentic Workflows that behave predictably under real-world data conditions.
What Are Conditions?
A Condition is a filter that runs inside an Agentic Workflow execution. It evaluates criteria against the context Record, Agentic Workflow variables, or both, and routes execution down one of exactly two paths based on the result. Conditions do not take action, they make decisions that determine what happens next. Here's what they do:
Acts as a filter step that evaluates criteria and routes execution: Conditions evaluate one or more criteria against available data and route execution down one of two paths based on whether those criteria are met.
Has a yes path or a no path: Every Condition has exactly two output paths: yes and no. There is no neutral outcome, and no way for a Condition to pass through without routing, unless you intentionally skip the Condition. Both paths must be accounted for in Agentic Workflow design, even if one path leads to no further steps, it must exist.
Creates an outcome that is visible in the execution history: Once a Condition executes, the path taken is recorded in the execution history for that step. This makes Conditions a useful diagnostic tool when tracing why an Agentic Workflow took a particular route.
Condition Types
Kizen Agentic Workflows support two Condition types. The type you choose determines how the yes/no decision is made, either through a deterministic filter evaluated against Record data and variables, or through an LLM that interprets unstructured content.
Filter Condition
A Filter Condition evaluates one or more filter criteria against the context Record or variable values and routes execution based on whether the criteria are met. Three filter options are available:
Is In Group / Is Not In Group: Routes execution based on whether the context Record is a member of a saved Group (or not). This is useful when you have pre-defined segments you want to reuse across Agentic Workflows without rebuilding the filter logic each time.
Custom Filters: Evaluates one or more criteria built directly in the Condition step. Filters can target any field on the context Record, values in Agentic Workflow variables, or both, and can be combined using AND and OR logic to express more complex criteria.
Note: Conditions that evaluate against a variable carry additional risk if the variable is blank at evaluation time. The result may be unpredictable depending on the operator used. See Blank Variable Risk in the Behavioral Caveats section below.
LLM Decision Step
The LLM Decision Step is a Condition variant that delegates the yes/no routing decision to an AI language model rather than a deterministic filter.
The LLM Decision Step routes execution based on a yes or no answer from a language model. You provide a prompt, the model evaluates it, and execution follows the path that matches the model's response. This is useful when the decision depends on something a filter cannot evaluate, such as the intent behind a free-text response, the sentiment of an email, or whether a description meets a qualitative standard.
The LLM Decision Step is not appropriate for deterministic logic where the correct answer can always be computed. For example, date comparisons, numeric evaluations, or field equality checks. For those cases, use a standard condition. Delegating deterministic logic to an LLM introduces unnecessary variance and the possibility of incorrect routing.
For guidance on good and poor LLM condition use cases, see AI Condition Steps in Agentic Workflow Code Steps.
How Conditions Evaluate
When a Condition executes, it evaluates criteria against the data available at that point in the execution sequence. The following describes what data is accessible, what comparison modes are supported, and how filters can be structured and validated:
Context Record and variable scope: Conditions evaluate against field values on the context Record and its related data, and any Agentic Workflow variables defined on the Agentic Workflow. Both the context Record and all variables are available to a condition step at the time it executes.
Comparison modes: Field-to-field comparisons evaluate one field against another field on the Record. Field-to-variable comparisons evaluate a field against a value stored in an Agentic Workflow variable. Field-to-value comparisons evaluate a field against a hardcoded static value. The right comparison mode depends on whether the value you are comparing against is fixed, dynamic, or derived from another part of the record.
Supported operators: Condition filters support a range of comparison operators including equals, does not equal, contains, does not contain, is blank, is not blank, and others. Available operators depend on the field type being evaluated. Operator selection also affects how blank values are handled at runtime. For more information, see Behavioral Caveats.
Filter groups and reusable filters: Conditions can be built using filter groups, which are logical groupings of criteria that combine AND and OR logic to express more complex evaluation rules. Reusable filters defined elsewhere in the platform can also be referenced within a Condition. When doing so, audit those filters for relative or user-context criteria that do not apply at Agentic Workflow runtime. For more information about Relative and Running User Filters, see Behavioral Caveats.
Filter group result preview: When configuring a Condition, you can view how many Records currently match the criteria of a filter group before activating the Agentic Workflow. Within the selected groups, select the filter group name to be taken to the matching Records.
Note: Your ability to view Filter Group Records may depend on your permissions. For more information, see Agentic Workflow Permissions (Topic Coming Soon).
Behavioral Caveats and Limitations
Conditions are straightforward to configure but carry several runtime behaviors that can produce unexpected results if not understood in advance. The following caveats apply to both standard conditions and, where noted, Goals.
Variable and Filter Behavior
Blank variable risk: If a Condition evaluates a variable that is blank at the time of evaluation, the result may be unpredictable depending on the operator used. Some operators handle blank values in ways that are not immediately obvious. A "does not equal" comparison against a blank variable, for example, may pass unexpectedly, routing execution down the yes path when the intent was to filter the Record out. This is one of the most common sources of unexpected Condition behavior in production Agentic Workflows.
The "Consider empty value an error" toggle: Variables include a configuration toggle called Consider empty value an error. When enabled, the variable errors immediately if assigned a blank value rather than silently storing it, preventing a blank variable from reaching a Condition undetected. This is the recommended mitigation for any variable used in a Condition where a blank value would produce incorrect routing. For full details, see Agentic Workflow Variables (Coming Soon).
Relative and running user filters are silently ignored: Some filter criteria are relative to the person who is currently logged in and running an action. For example, "owner is me" resolves to whichever user is active at that moment. These are called running user or relative filters. Because Agentic Workflows execute in the Agentic Workflow context rather than in the context of any specific user, these filters have no user to resolve to at runtime and are silently ignored. The Agentic Workflow proceeds as if that criterion does not exist. Before using a reusable filter group in an Agentic Workflow condition, audit it for relative or running user criteria and remove or replace them.
"My Records" filter behavior: Filters that use "My Records" do not behave as expected in Agentic Workflow conditions. Because Agentic Workflows do not run in user context, "My Records" has no user to resolve to at runtime and is silently ignored. If a Condition relies on ownership or association logic, use an explicit field comparison instead. For example, comparing an owner field directly against a specific team member value or an initialized variable.
Error Behavior
Conditions do not support error handling: Conditions do not have configurable error handling. There is no retry behavior and no error path. If a Condition encounters a problem it cannot evaluate through, execution pauses rather than continuing down either path.
Pause on error requires manual path selection: If a Condition errors, the execution is paused on that step. When manually restarted, the execution will attempt to re-run the Condition. If the user chooses to skip the Condition instead, they must select which path, yes or no, the execution should continue down. Skipping a paused Condition requires a deliberate path selection and is the only way to bypass a Condition that cannot be evaluated.
Goals share this behavior: Goals share the same pause-and-select-path behavior when they encounter an error. A path must be manually selected before the Agentic Workflow can continue. For full detail, see Agentic Workflow Goals (Topic Coming Soon).
LLM Decision Step confidence threshold: The LLM Decision Step includes a confidence threshold setting that determines how the step handles low-confidence responses from the model. For full details on how this setting works and how to configure it, see LLM/AI Action Steps (Coming Soon).
What's Next
With a clear understanding of how Conditions evaluate criteria and route execution, the next step is to learn about Actions, which are the units of work that produce outcomes within an Agentic Workflow. Together, Conditions and Actions form the core decision and execution layer of any Agentic Workflow's logic.
Continue to Agentic Workflow Actions (Topic Coming Soon) to learn about every supported action type and how each behaves.
Last updated
Was this helpful?