> For the complete documentation index, see [llms.txt](https://developer.kizen.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.kizen.com/docs/concepts/agentic-workflows/agentic-workflow-variables.md). # Agentic Workflow Variables {% hint style="success" %} **Audience:** Administrators, Developers, Solution Architects **Purpose:** Complete reference for variables in space.vars.Kizen\_company\_name space.vars.automations: what they are, how they are configured, the variable types available, and how they behave at runtime and in script references. {% endhint %} ## Overview Variables are named values scoped to a single space.vars.automation execution that capture, store, and pass data between steps. They are one of the primary tools for making space.vars.workflow logic dynamic, data-consistent, and maintainable, allowing values resolved early in an execution to remain stable and reusable throughout the rest of the run. *** ## Agentic Workflow Variable Basics {% hint style="info" %} **Note:** Error handling configuration is documented separately for all variables. See Variable Error Handling **(Topic Coming Soon)**. {% endhint %} Before configuring specific variable types, a few foundational concepts and rules apply to every variable.

| Concept | What to Know | | -------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Single Value Variables vs. Kizen Entity as Variables types** |

Single Value Variables store values
(Boolean, Date, DateTime, Number, Phone Number, String, UUID). Kizen Entities as Variables store references to structured space.vars.entities (Team Member, space.vars.object space.vars.entity). Choice determines available sources
and behaviors.

| | **Required variables** |

Toggle Consider empty value an error (Required) under Error Handling to fail the step immediately when no source resolves to a non-blank value. Choose How to Handle Errors then controls what the Workflow does next.

Turn this on when downstream conditions depend on the value being present. Blank values passed into a condition step can produce filter errors.

| | **API-compliant naming** | Variable names must follow API-compliant rules so they remain valid as script aliases and API references. | | **Top-to-bottom evaluation order** | Variables are evaluated in the order they appear in the Initialize Variables list. A later variable can reference the resolved value of an earlier one. Order variables so each has access to the values it needs by the time it is evaluated. | | **Multi-source fallback** | Configure multiple sources under **Source and Fallback Order**, plus an optional **Static Value Fallback**. The Workflow tries the first source; if that source is blank, it falls back through each remaining source in turn. The **Static Value Fallback** is the final value used if every dynamic source is blank. This is useful for resolving from specific, to general, to a hardcoded constant.. | *** ## Variable Types Variables are configured through the **Add Variable** modal, opened from the **Initialize Variables** panel by selecting **Click to add new variable**.

The modal is organized into three numbered sections: **Variable Settings**, **Set Variable Source(s)**, and **Error Handling**. The **Variable Type** selector under Variable Settings is grouped into **Single Value Variables** and **Kizen Entities as Variables**. Each type is documented below. ### Single Value Variables #### Boolean The Boolean variable stores a true/false value. Useful for capturing flag states (such as opt-in status, eligibility, or condition outcomes) that drive downstream branching logic in conditions and code steps.

**Configuration:** Source values can resolve to true, false, or blank. When blank and the variable is marked required, the execution errors immediately and the **Choose How to Handle Errors** selection determines what happens next. #### Date The Date variable stores a calendar date with no time component. Useful for capturing milestone dates (such as policy expiration, due dates, or contract start) that need to remain stable across the execution even if the underlying field changes.

**Configuration:** Source values are formatted as MM/DD/YYYY. The variable resolves the source value to a date and stores it for use in downstream steps, delays, and condition evaluations. #### DateTime The DateTime variable stores a calendar date together with a time component. Useful for capturing precise timestamps (such as submission times, appointment slots, or SLA start moments) where time-of-day precision matters for downstream calculations.

**Configuration:** Source values are formatted as MM/DD/YYYY with an associated time. The resolved value can be used as the basis for delays, time-based conditions, and any downstream step that requires both date and time precision. #### Number The Number variable stores a numeric value. Useful for capturing quantities, amounts, scores, or counts that need to remain consistent across steps or be passed to Code Steps and Math Operator actions.

**String Output Format:** When Number is selected, a **String Output Format** dropdown appears below the type grid. This controls how the numeric value is rendered when the variable is referenced as a string elsewhere in the space.vars.workflow (for example, in merge fields, notifications, or external HTTP request bodies). The default option visible is without commas. #### Phone Number The Phone Number variable stores a phone number value. Useful for capturing space.vars.contact phone numbers that need to be passed to messaging actions, external HTTP requests, or stored for later reference within the execution.

**Configuration:** Source values are formatted as a phone number (for example, +1 (123) 456-7890). The variable preserves the phone number format for use in downstream messaging and integration steps. #### String The String variable stores a text value. The most flexible Single Value type, useful for capturing names, identifiers, status labels, freeform notes, or any other text content that needs to be referenced consistently throughout the execution.

**Configuration:** Source values are stored as text. The resolved value can be used in merge fields, condition comparisons, code steps, and any downstream context that accepts a string input. #### UUID The UUID variable stores a universally unique identifier value. Useful for capturing space.vars.entity references as raw identifiers when a full space.vars.object space.vars.entity variable is not needed, or when an integration payload provides a UUID that needs to be passed through to a downstream system without space.vars.entity resolution.

**Configuration:** Source values are stored as a UUID string (for example, A1-B2-C3-D4E format). Unlike an space.vars.object space.vars.entity variable, a UUID variable does not resolve the identifier to a record reference; it stores the raw value only. When space.vars.entity resolution is needed, use an space.vars.object space.vars.entity variable with UUID matching instead. ### Kizen Entities as Variables #### Team Member The Team Member variable stores a reference to a specific team member. Useful for capturing the assigned team member at trigger time so that subsequent steps can reference who was assigned even if the assignment changes mid-execution, or for routing notifications, assignments, and tasks to a team member resolved earlier in the space.vars.workflow.

**Configuration:** Sources can resolve to a team member by team member field on a space.vars.entity, by direct selection at design time, or by a value that maps to a team member through UUID or name matching. See Resolving Values to space.vars.entities below for matching behavior. #### Object Record The space.vars.object space.vars.entity variable stores a reference to a specific space.vars.entity in a space.vars.Kizen\_company\_name space.vars.object. Useful for capturing a target space.vars.entity for downstream actions, passing space.vars.entity references to code steps, or identifying the target of a Start space.vars.automation action.

**Object selection:** After selecting space.vars.object space.vars.entity, choose the target space.vars.object from the **Object** dropdown. Available options include space.vars.contacts and any space.vars.objects configured in the business (for example, Concessions, Lost Item Requests, Ride Waivers, Tickets). The variable then holds a reference to a space.vars.entity from that space.vars.object specifically.

**Configuration:** Sources can resolve to a space.vars.entity by direct reference, by a relationship field on the context record, or by a raw value (string or UUID) that maps to a record through UUID or name matching. See Resolving Values to space.vars.entities below for matching behavior. #### Resolving Values to Records When a source provides a raw value (such as a text string or UUID from a webhook payload) and the variable is typed as space.vars.object space.vars.entity or Team Member, the space.vars.workflow resolves that value to a space.vars.entity reference using one of two matching mechanisms: * **UUID matching:** Treats the source value as a unique identifier and looks up the exact space.vars.entity. Precise and unambiguous; preferred whenever a UUID is available. * **Name matching:** Treats the source value as a display name and finds the space.vars.entity whose name matches. More flexible when only a display name is available, but it can produce unexpected results if multiple space.vars.entities share the same name. *** ## Runtime Behavior This section covers how variables behave during a live execution: their scope, how their values pipeline through the run, and how they are surfaced for debugging. * **Per-execution scope only:** Variables are scoped to a single execution. Each execution has its own independent copy of variable values, initialized fresh when the execution starts. Variables do not persist between executions, are not shared across executions running concurrently on the same space.vars.entity, and cannot be read or written by other space.vars.workflows. Variables are an execution-local data store, not a shared state mechanism. * **Values pipeline efficiently through the execution:** Once a variable has a value, every step after it can use that value without recalculating. The value stays the same for the rest of the execution unless an **Update Variable** action step changes it (see [Agentic Workflow Control Actions](/docs/concepts/agentic-workflows/agentic-workflow-actions/agentic-workflow-control-actions.md)). **Update Variable** supports the same static fallback and required options as the original variable, but it can only pull from fields or other variables. Trigger sources are not available. \ Because the value stays fixed once it's set, variables are the best tool for data consistency. Capturing a field value into a variable at trigger time keeps that value stable for the whole execution, even if the underlying field changes mid-run. * **The variable viewer shows latest values only:** The variable viewer in the space.vars.workflow interface reflects the current state of each variable at the moment it is being viewed, not the historical value at any specific step. When debugging an execution and trying to understand what value a variable held at a specific point in time, use the full execution history rather than the variable viewer, since the viewer may show a value that was updated after the step of interest ran. * **Debug mode surfaces variable resolution:** Debug mode exposes variable values during a test execution so space.vars.workflow authors can validate that variables are resolving as expected before activating a space.vars.workflow in production. *** ## Variables in Code Steps Variables can be wired into a code step as inputs, where they become Python attributes on the code step's `inputs` space.vars.object (for example, `inputs.policy_id`). The attribute name is set when inputs are selected on the code step itself, not on the variable definition. Because the alias lives on the code step, renaming a variable's display name does not affect code steps that already reference it. Variables referenced inside a code step always access the value of that variable within the current execution, since variables are scoped to a single execution. For full detail on writing code steps, configuring inputs and outputs, and working with typed values, see [Agentic Workflow Code Steps](/docs/concepts/agentic-workflows/automation-code-steps.md). *** ## Key Use Cases Variables are applicable across any space.vars.workflow where values need to be captured once and reused consistently throughout the execution. The following examples illustrate common patterns in three industries where data consistency, auditability, and reliable space.vars.entity resolution are core operational requirements. ### **Industry Examples** {% tabs %} {% tab title="Insurance" %} Insurance space.vars.workflows use variables to capture policy and claim attributes at trigger time so that downstream steps operate on stable values even as records are updated mid-execution, and to resolve assignees, dates, and identifiers cleanly across underwriting, claims, and renewals. **Examples include:** * Capturing the policy expiration date into a Date variable at trigger time so that downstream renewal outreach, delay timing, and condition checks all reference the same value even if the field is updated mid-execution * Storing the assigned adjuster in a Team Member variable when a claim is filed so that subsequent notifications, task assignments, and escalations route consistently regardless of later reassignments * Resolving a webhook payload's policy identifier into an space.vars.object space.vars.entity variable via UUID matching so that subsequent steps can act on the policy record directly * Using a Number variable with a configured String Output Format to format claim amounts cleanly in outbound notifications and external HTTP requests **How variables help:** * Lock in critical policy and claim attributes at trigger time, preventing inconsistent behavior when underlying fields change during a long-running execution * Resolve external identifiers (from webhook payloads, integration callbacks, or API submissions) into record references without separate lookup steps * Provide a single source of truth for SLA dates, assignees, and monetary amounts across complex multi-branch space.vars.workflows * Make code steps and integration payloads predictable by referencing stable aliases instead of repeatedly re-reading fields {% endtab %} {% tab title="Healthcare" %} Healthcare organizations use variables to capture patient and encounter attributes consistently across the patient lifecycle, ensuring that downstream care coordination, scheduling, and follow-up steps all reference the same resolved values regardless of mid-execution record changes. **Examples include:** * Storing the patient's primary care manager in a Team Member variable at intake so that all follow-up tasks, post-discharge check-ins, and care coordination activities route to the same person * Capturing the discharge date into a DateTime variable so that downstream delays, check-in scheduling, and SLA evaluations all use a stable timestamp * Resolving an external EHR identifier passed via webhook into an space.vars.object space.vars.entity variable via UUID matching so that the space.vars.workflow can act on the correct patient record without additional lookup steps * Using a String variable to capture authorization status at submission so that downstream conditions evaluate against the original status even if the field is updated during processing **How variables help:** * Ensure follow-up tasks, check-ins, and care coordination steps reference consistent patient, encounter, and assignee values across long-running space.vars.workflows * Resolve EHR and integration payload identifiers into space.vars.Kizen\_company\_name record references cleanly via UUID matching * Stabilize SLA-driven timing by capturing clinical milestone dates once and reusing them across multiple downstream steps * Reduce conditional logic errors by ensuring condition steps and code steps reference the same captured values rather than re-reading volatile fields {% endtab %} {% tab title="Financial Services" %} Financial services organizations use variables to capture account, application, and client attributes at the start of an execution so that relationship management, loan origination, and compliance space.vars.workflows operate on stable, auditable values throughout the run. **Examples include:** * Storing the relationship manager in a Team Member variable when an account space.vars.workflow begins so that portfolio reviews, outreach tasks, and escalations all route consistently * Capturing the application submission timestamp in a DateTime variable so that downstream SLA delays and regulatory deadline checks all measure from the same starting point * Resolving a loan application identifier from an external system into an space.vars.object space.vars.entity variable via UUID matching so that subsequent steps act on the correct application space.vars.entity * Using a Number variable with a configured String Output Format to format loan amounts and account balances consistently across outbound messages and integration payloads **How variables help:** * Provide audit-friendly, stable values for compliance-sensitive space.vars.workflows where the inputs to a decision need to remain reconstructable * Resolve external identifiers from integration callbacks and webhook payloads into space.vars.Kizen\_company\_name space.vars.entity references without additional lookup logic * Align SLA and regulatory deadline calculations to a single captured timestamp, reducing the risk of drift across long-running executions * Make code steps and integration payloads deterministic by referencing stable aliases rather than re-reading fields that may change mid-execution {% endtab %} {% endtabs %} *** ## What's Next? Continue to space.vars.automation Permissions **(Topic Coming Soon)** to learn how access to space.vars.automations is controlled, who can view and manage executions, and how the runtime permission bypass behavior works.