Data Variable Node
The Data Variable node provides database-backed persistent storage that survives across workflow executions and service restarts. Data is automatically scoped by chat session and tenant, ensuring proper isolation in multi-tenant environments. The node supports SET, GET, CHECK, and DELETE operations for complete data lifecycle management.
How It Works
Unlike workflow variables which only exist during a single workflow run, data variables persist in the database across multiple executions. When data is stored, it is saved with automatic scoping by chat session and tenant. This makes the node suitable for maintaining context across multiple user interactions, storing user preferences, caching expensive computation results, or managing workflow state that persists between executions.
The node provides four operations for data lifecycle management:
- SET stores new values or overwrites existing ones, reading data from workflow variables and persisting it to the database
- GET retrieves previously stored values from the database and places them into workflow variables for the current execution
- CHECK verifies whether specific keys exist in storage without retrieving their values
- DELETE removes keys from storage when data is no longer needed
All operations support variable interpolation using ${variable_name} syntax, enabling dynamic key and value resolution based on workflow context. For example, ${user_id} as a key stores user-specific data, or ${extracted_summary} as a value stores output from a previous node. The node automatically handles JSON serialization for complex data types, including objects, arrays, and nested structures. Operations return counts of affected items (for SET and DELETE) or boolean existence results (for CHECK), which can be stored in optional output variables for downstream conditional logic.
Configuration Parameters
Operation
Operation (Dropdown, Required): Determines the data variable operation to perform: SET, GET, CHECK, or DELETE.
The operation parameter determines how the node interacts with persistent storage:
| Operation | Configuration | Output | Purpose |
|---|---|---|---|
| SET | Add key-value pairs via Add Value. Each entry: Database Field (field name), Value (data to store). Optional Output Field stores count of items set. | Count of items set (optional) | Saving user preferences, session data, computation results, or persistent workflow state |
| GET | Add fields via Add Key. Each entry: Database Field (field to retrieve), Output Variable (storage location). | Retrieved values in specified variables | Loading previously saved data or restoring context from previous interactions |
| CHECK | Add fields via Add Key. Each entry: Database Field (field to verify), Output Variable (stores true/false). | Boolean existence results in specified variables | Conditional logic based on data existence, verifying prerequisites before processing |
| DELETE | Add field names via Add Key. Optional Output Field stores count deleted. | Count deleted (optional) | Cleaning up temporary data, removing outdated information, resetting user-specific state |
Values To Set
For SET operation: Key-value pairs define data stored in persistent storage. At least one entry is required. Database Field specifies the field name in persistent storage (supports static text and variable interpolation with ${variable_name}). Value specifies the data to store (supports static text and variable interpolation to read from workflow variables). JSON serialization handles complex data types like objects and arrays automatically.
Common patterns: Store user ID (user_id → ${extracted_user_id}), save summary (conversation_summary → ${llm_summary}), cache results (search_results → ${api_response}).
Keys To Get
For GET operation: Fields to retrieve from persistent storage. At least one entry is required. Database Field specifies the field name to retrieve (supports static text and variable interpolation). Output Variable specifies the workflow variable where the retrieved value is stored. If a key doesn't exist, the output variable receives null.
Common patterns: Load user ID (user_id → userId), retrieve summary (conversation_summary → previousSummary), restore cache (search_results → cachedResults).
Keys To Check
For CHECK operation: Fields to verify existence in persistent storage. At least one entry is required. Database Field specifies the field name to check (supports static text and variable interpolation). Output Variable specifies the workflow variable where the boolean result (true if exists, false if not) is stored. This operation supports conditional branching based on whether data has been previously stored.
Common patterns: Check user exists (user_id → hasUser), verify cache (search_results → hasCachedResults), validate state (workflow_state → hasState).
Keys To Delete
For DELETE operation: Field names to remove from persistent storage. At least one entry is required. Each entry specifies a database field name to delete (supports static text and variable interpolation with ${variable_name}). The operation returns the count of successfully deleted items, which can optionally be stored in an Output Field variable.
Common patterns: Remove temporary data (temp_data), clear user session (user_session_${session_id}), delete cache (cached_results).
Output Field
Optional variable to store the operation result. For SET and DELETE operations, stores the count of items affected (number of fields set or deleted). For GET and CHECK operations, this parameter is not applicable—results are stored in the Output Variable specified for each key.
Common naming patterns: items_set, items_deleted, operation_count.
Common Parameters
This node supports common parameters shared across workflow nodes, including Logging Mode and Wait For All Edges. For detailed information, see Common Parameters.
Best Practices
- Establish descriptive and consistent field naming conventions across workflows, such as prefixing with scope (
user_,session_,cache_), to avoid naming conflicts - Store only necessary data to minimize database storage and improve performance; avoid large objects or redundant information
- Implement defensive data access patterns by using CHECK operation before GET, which handles missing data gracefully
- Regularly remove temporary data with DELETE operations to prevent accumulation of obsolete information
- Variable interpolation for dynamic keys enables flexible and reusable workflow designs when storing user-specific or context-specific data
Limitations
- Session and Tenant Scoping: Data variables are automatically scoped by chat session ID and tenant ID. Data stored in one session cannot be accessed from another session, and data is isolated between tenants.
- No Cross-Session Access: Data variables cannot be shared across different chat sessions. Each session maintains its own isolated storage.
- Database Dependency: Operations require database connectivity. If the database is unavailable, operations fail unless Continue on Failure is enabled.
- JSON Serialization: Complex Python objects are automatically serialized to JSON. Custom objects must be JSON-serializable or will cause errors.
- No Null Values in SET: SET operation rejects null values. DELETE operation resets variables instead of setting to null.
- Key Name Constraints: Database field names must follow database naming conventions (typically alphanumeric with underscores, no special characters).