Skip to main content
When automating form-heavy workflows, you often need to pass many related fields. Instead of creating a separate variable for each field, you can pass structured JSON objects and access nested properties directly in your prompts.

The Problem

Consider a loan document with a “Section G” containing many fields. Without structured inputs, you’d need to define separate variables for each:
This becomes unwieldy and error-prone.

The Solution: Nested Access

With structured inputs, you can pass a single JSON object and access nested properties directly:
Then when creating a run, you simply pass:

Syntax Reference

Dot Notation

Access object properties with .:

Bracket Notation (Arrays)

Access array elements by index:

Bracket Notation (Special Keys)

For keys with special characters, use bracket notation with quotes:

Combining Notations

Chain any combination for deeply nested structures:

Works Across All Variable Types

Structured access works consistently for all three variable types:
Need these delimiters to appear literally instead of resolving as variables? Escape the opening delimiter:
  • \{customer_name} renders as literal {customer_name}
  • \{{current_status}} renders as literal {{current_status}}
  • \{$support_pin} renders as literal {$support_pin}
This works in workflow prompt text and in input values you pass at run start.

Sensitive Inputs Example

Runtime Values Example

When a focused_action sets a runtime value as an object:
You can then access nested properties in subsequent steps:

Using Refs in Chains

When running multiple workflows in a session chain, you can use $ref to pass outputs from previous steps as inputs to later steps. Refs work inside structured inputs, allowing you to build complex input objects from prior outputs.

Basic ref inside structured input

Building structured inputs from multiple refs

You can mix refs with literal values anywhere in the structure:
Cyberdesk keeps $ref values as references when you create the run, validates them against the destination input schema when possible, and resolves them at execution time before the receiving workflow uses them. Your workflow prompt receives the actual values, not the $ref syntax.
For more on refs and chains, see Sessions and Chains.

Error Handling

Type Mismatches (Fails the Run)

If you try to access a nested property on a value that isn’t an object or array, the run fails immediately with a clear error:
This catches configuration errors early, saving you time and usage costs.

Missing Fields (Uses __EMPTY__)

If a nested path simply doesn’t exist, it’s replaced with the __EMPTY__ sentinel value (same behavior as regular empty inputs):
This allows workflows to gracefully handle optional nested fields. If you want to intentionally blank out a field that already has a value, use __CLEAR__ instead of __EMPTY__.

Array Out of Bounds

Accessing an array index that doesn’t exist is treated as missing (not a type error):

Backward Compatibility

Existing workflows continue to work exactly as before:
  • {variable} with a string value → replaced with the string
  • {variable} with an object/array value (no nested access) → JSON stringified

Best Practices

Group Related Fields

Organize related inputs into logical objects (e.g., patient, billing, shipping) rather than dozens of flat variables.

Use Consistent Structures

Define a standard schema for your inputs across workflows. This makes SDK integration easier and reduces errors.

Validate Early

Cyberdesk validates type mismatches at run start. Structure your inputs correctly to catch errors before execution begins.

Handle Optional Fields

Missing nested fields become __EMPTY__. Design your prompts to handle this gracefully for optional data.

Real-World Example: Healthcare Form

This approach transforms 15+ separate variables into a clean, hierarchical structure that mirrors your actual data model.