Agentic Workflow Variables
Audience: Administrators, Developers, Solution Architects
Purpose: Complete reference for variables in Kizen Agentic Workflows: what they are, how they are configured, the variable types available, and how they behave at runtime and in script references.
Overview
Variables are named values scoped to a single Agentic Workflow execution that capture, store, and pass data between steps. They are one of the primary tools for making 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
Note: Error handling configuration is documented separately for all variables. See Variable Error Handling (Topic Coming Soon).
Before configuring specific variable types, a few foundational concepts and rules apply to every variable.
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 Records (Team Member, Object Record). 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 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 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 Record references as raw identifiers when a full Object Record variable is not needed, or when an integration payload provides a UUID that needs to be passed through to a downstream system without Record resolution.
Configuration: Source values are stored as a UUID string (for example, A1-B2-C3-D4E format). Unlike an Object Record variable, a UUID variable does not resolve the identifier to a record reference; it stores the raw value only. When Record resolution is needed, use an Object Record 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 Workflow.
Configuration: Sources can resolve to a team member by team member field on a Record, 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 Records below for matching behavior.
Object Record
The Object Record variable stores a reference to a specific Record in a Kizen Object. Useful for capturing a target Record for downstream actions, passing Record references to code steps, or identifying the target of a Start Agentic Workflow action.
Object selection: After selecting Object Record, choose the target Object from the Object dropdown. Available options include Contacts and any Objects configured in the business (for example, Concessions, Lost Item Requests, Ride Waivers, Tickets). The variable then holds a reference to a Record from that Object specifically.
Configuration: Sources can resolve to a Record 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 Records 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 Object Record or Team Member, the Workflow resolves that value to a Record reference using one of two matching mechanisms:
UUID matching: Treats the source value as a unique identifier and looks up the exact Record. Precise and unambiguous; preferred whenever a UUID is available.
Name matching: Treats the source value as a display name and finds the Record whose name matches. More flexible when only a display name is available, but it can produce unexpected results if multiple Records 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 Record, and cannot be read or written by other 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). 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 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 Workflow authors can validate that variables are resolving as expected before activating a 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 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.
Key Use Cases
Variables are applicable across any 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 Record resolution are core operational requirements.
Industry Examples
Insurance 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 Object Record 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 Workflows
Make code steps and integration payloads predictable by referencing stable aliases instead of repeatedly re-reading fields
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 Object Record variable via UUID matching so that the 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 Workflows
Resolve EHR and integration payload identifiers into Kizen 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
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 Workflows operate on stable, auditable values throughout the run.
Examples include:
Storing the relationship manager in a Team Member variable when an account 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 Object Record variable via UUID matching so that subsequent steps act on the correct application Record
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 Workflows where the inputs to a decision need to remain reconstructable
Resolve external identifiers from integration callbacks and webhook payloads into Kizen Record 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
What's Next?
Continue to Agentic Workflow Permissions (Topic Coming Soon) to learn how access to Agentic Workflows is controlled, who can view and manage executions, and how the runtime permission bypass behavior works.
Last updated
Was this helpful?