# Agentic Workflow Conditions {% hint style="success" %} **Audience:** Administrators, Developers, Solution Architects **Purpose:** Defines what space.vars.condition\_steps 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. {% endhint %} ## Overview space.vars.condition\_steps are the primary mechanism for introducing decision logic into an space.vars.automation. Every space.vars.condition\_step 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 space.vars.condition\_steps evaluate, and where they can fail, is essential for designing space.vars.automations that behave predictably under real-world data conditions. *** ## What Are Conditions? A space.vars.condition\_step is a filter that runs inside an space.vars.automation execution. It evaluates criteria against the context space.vars.entity, space.vars.automation variables, or both, and routes execution down one of exactly two paths based on the result. space.vars.condition\_steps 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:** space.vars.condition\_steps 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 space.vars.condition\_step has exactly two output paths: yes and no. There is no neutral outcome, and no way for a space.vars.condition\_step to pass through without routing, unless you intentionally skip the space.vars.condition\_step. Both paths must be accounted for in space.vars.automation 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 space.vars.condition\_step executes, the path taken is recorded in the execution history for that step. This makes space.vars.condition\_steps a useful diagnostic tool when tracing why an space.vars.automation took a particular route. *** ## Condition Types space.vars.Kizen\_company\_name space.vars.automations support two space.vars.condition\_step types. The type you choose determines how the yes/no decision is made, either through a deterministic filter evaluated against space.vars.entity data and variables, or through an LLM that interprets unstructured content. ### Filter Condition A Filter space.vars.condition\_step evaluates one or more filter criteria against the context space.vars.entity 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 space.vars.entity is a member of a saved Group (or not). This is useful when you have pre-defined segments you want to reuse across space.vars.automations without rebuilding the filter logic each time. * **Custom Filters:** Evaluates one or more criteria built directly in the space.vars.condition\_step step. Filters can target any field on the context space.vars.entity, values in space.vars.automation variables, or both, and can be combined using AND and OR logic to express more complex criteria.

{% hint style="info" %} **Note:** space.vars.condition\_steps 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](#behavioral-caveats-and-limitations) section below. {% endhint %} ### LLM Decision Step The LLM Decision Step is a space.vars.condition\_step 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](/docs/concepts/agentic-workflows/automation-code-steps.md). *** ## How Conditions Evaluate When a space.vars.condition\_step 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:** space.vars.condition\_steps evaluate against field values on the context space.vars.entity and its related data, and any space.vars.automation variables defined on the space.vars.automation. Both the context space.vars.entity 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 space.vars.entity. Field-to-variable comparisons evaluate a field against a value stored in an space.vars.automation 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:** space.vars.condition\_step 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](#behavioral-caveats-and-limitations). * **Filter groups and reusable filters:** space.vars.condition\_steps 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 space.vars.condition\_step. When doing so, audit those filters for relative or user-context criteria that do not apply at space.vars.automation runtime. For more information about Relative and Running User Filters, see [Behavioral Caveats](#behavioral-caveats-and-limitations). * **Filter group result preview:** When configuring a space.vars.condition\_step, you can view how many space.vars.entities currently match the criteria of a filter group before activating the space.vars.automation. Within the selected groups, select the filter group name to be taken to the matching space.vars.entities. {% hint style="info" %} **Note:** Your ability to view Filter Group space.vars.entities may depend on your permissions. For more information, see Agentic Workflow Permissions **(Topic Coming Soon)**. {% endhint %} *** ## Behavioral Caveats and Limitations space.vars.condition\_steps 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 space.vars.condition\_step 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 space.vars.entity out. This is one of the most common sources of unexpected space.vars.condition\_step behavior in production space.vars.automations. * **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 space.vars.condition\_step undetected. This is the recommended mitigation for any variable used in a space.vars.condition\_step 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 space.vars.automations execute in the space.vars.automation 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 space.vars.automation proceeds as if that criterion does not exist. Before using a reusable filter group in an space.vars.automation 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 space.vars.automation conditions. Because space.vars.automations do not run in user context, "My Records" has no user to resolve to at runtime and is silently ignored. If a space.vars.condition\_step 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:** space.vars.condition\_steps do not have configurable error handling. There is no retry behavior and no error path. If a space.vars.condition\_step encounters a problem it cannot evaluate through, execution pauses rather than continuing down either path. * **Pause on error requires manual path selection:** If a space.vars.condition\_step errors, the execution is paused on that step. When manually restarted, the execution will attempt to re-run the space.vars.condition\_step. If the user chooses to skip the space.vars.condition\_step instead, they must select which path, yes or no, the execution should continue down. Skipping a paused space.vars.condition\_step requires a deliberate path selection and is the only way to bypass a space.vars.condition\_step 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 space.vars.automation 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 space.vars.condition\_steps evaluate criteria and route execution, the next step is to learn about Actions, which are the units of work that produce outcomes within an space.vars.automation. Together, space.vars.condition\_steps and Actions form the core decision and execution layer of any space.vars.automation's logic. Continue to Agentic Workflow Actions **(Topic Coming Soon)** to learn about every supported action type and how each behaves.