SDO Node (Session Data Object)

Node

Session Data Object (SDO)

Description

The SDO(Session Data Object) Node is used to create or modify session-scoped variables during the IVR call flow. These variables are not tied to the CDO (Call Data Object), but are maintained separately within the the duration of the call.

This node enables storing, modifying, and referencing dynamic data, making it extremely useful for managing user inputs, API responses, prompts, or any temporary values throughout the call journey.

You can use this node anywhere in the flow, and its values can be accessed later in other nodes using the SDO.{key} notation.

Use Cases

Saving menu selections or digit entries
Holding API response data or computed values
Storing flags or session-specific preferences
Passing dynamic content to prompt, HTTP, Queue, or Lua Code nodes etc

⚙️ Configuration

Field	Description	Example
Name	A user-friendly label for this node in the designer.	`Set Caller Info`
SDO	One or more key-value pairs to be stored. Keys must be strings. Values can be of multiple types, described below.	See examples below

🔡 Supported Value Types for SDO

Type	Description	Example
String	Simple text or string literals	`"customer"`
Number	Integer or floating-point numbers	`100` or `45.6`
Boolean	Logical values	`true` or `false`
JSON	Structured JSON objects for complex values	`{"plan": "premium", "active": true}`
Null	Special value that translates to `nil` in Lua	`null`

🧠 Behavior

Once set, these SDO values can be reused in HTTP, Menu, Digit, Lua Code, or any other nodes supporting dynamic values.
For example:
- To set SDO.lang = "en" early in the flow
- And then use it later in HTTP header: Accept-Language: SDO.lang

📌 Comparison with CDO Node

	SDO Node	CDO Node
Contains	Call Data Information like `caller_id`, `ani`	Custom session data maintained by IVR designer
Purpose	Get the call information	Maintain the custom data to manage the IVR flow

Best Practices

Use clear & consistent key names (e.g. userLang, retryCount)
Set important SDOs early in the flow
Store API responses or user inputs for reuse
Use null only if you handle it properly, in Lua (nil)
Inject SDOs into API headers/body or dynamic prompts
Prefer JSON type for structured data
Don't duplicate data already in CDO