Expression Fields in Forms
Atlas Form fields that support expressions show an expression toggle in the node configuration panel. Enabling the toggle switches the input from a plain text field to an expression editor. The backend stores the raw expression string and resolves it at execution time.
Enabling Expressions on a Form Field
In the Atlas Form field definition (JSON schema), set supportsExpressions: true on any field that should allow expression input:
// Atlas Form field definition
{
"key": "recipientEmail",
"label": "Recipient Email",
"type": "text",
"supportsExpressions": true, // ← enables the expression toggle
"expressionLanguage": "auto", // "auto" | "javascript" | "cel"
"required": true,
"placeholder": "e.g. alice@example.com or @{output:form-1.email}"
}Field Behaviour With Expressions
| State | Input Mode | Stored Value | Resolved As |
|---|---|---|---|
| Expression OFF | Plain text input | "alice@example.com" |
Literal string — no resolution |
| Expression ON | Expression editor with syntax highlighting | "@{output:form-1.email}" |
Resolved to the actual email value at runtime |
expressionLanguage Values
| Value | Effect |
|---|---|
"auto" | Designer auto-detects from the expression prefix (@{js:...}, @{output:...} etc.) |
"javascript" | Forces Jint evaluation for the whole field value |
"directive" | Directive-only — no Jint; only @{output:...}, @{var:...} etc. |
Frontend Role
The Flow Studio designer stores expression strings exactly as the user typed them. It does not evaluate expressions — it only renders the syntax highlight and provides an autocomplete picker for known node outputs. Evaluation happens entirely on the backend during execution.
// What is stored in the ProcessElement.Configuration JSON:
{
"recipientEmail": "@{output:form-submission-1.email}",
"subject": "New order from @{output:form-submission-1.firstName}",
"priority": "high" // ← plain literal, no expression
}Validation in the Designer
When the user saves the workflow, the designer sends each expression field value to IExpressionEvaluator.ValidateExpressionAsync() (via the validation API). The designer highlights syntax errors in real time without executing the expression. Only syntactic correctness is checked at design time — semantic validity (e.g. whether a referenced node exists) is checked at execution time.
supportsExpressions: true is set but the user types a plain value (no @{... sigil), the resolver treats it as a literal string and does not invoke the expression engine. The overhead of the resolver is minimal for literal fields.