Binding syntax reference

A binding reads a value from the process flow’s data into a field, a token, or a condition. This topic lists the binding forms and the mistakes to avoid. For the two kinds of data a binding reads, see How data moves through a process flow.

Binding forms

Binding Reads

{Outputs>/<activity>/<property>}

A value from a specific earlier step’s output, named by its activity identifier.

{InterfaceData>/<property>}

A value from interface data, the global store for the run.

{/approverDecision}

The action a person selected on the previous User Task.

You can drag an input from a node’s Inputs panel into a field, which writes the binding for you.

Expressions

To compare or compute values, use an expression. An expression is wrapped in {= }, and reads a value with ${ }. For example:

{= ${InterfaceData>/candidate/yearsOfExperience} >= 5 }

Expressions are used in condition rules. See Condition operators and operand types.

How a condition evaluates

A condition must evaluate to true or false. If it evaluates to anything else, such as a bare value or a missing field, the path is not taken, and a warning is written to the logs. Write a condition as a comparison of a bound value against an expected value, for example {= ${InterfaceData>/name} === "Nora" }, rather than a bare binding such as {= ${InterfaceData>/name} }.

A comparison is strict on both value and type. A number matches a number, and text matches text. {= ${InterfaceData>/count} === 5 } matches the number 5, while {= ${InterfaceData>/count} === "5" } matches the text "5". The number 5 and the text "5" are not equal, so compare a field that holds a number with a number.

A few more points hold when you write a condition:

  • Single quotes and double quotes both work for text, for example === "Nora" and === 'Nora'.

  • Extra spaces inside the expression do not change the result.

  • If a path is not taken when you expected it to be, check the logs for a condition-evaluation warning. A misspelled binding or a type mismatch is the usual cause.

Valid and invalid bindings

The following interface data is used for the examples:

{ "contacts": [ { "firstname": "Sofia" }, { "firstname": "Neha" } ] }
Binding Result

{InterfaceData>/contacts/0/firstname}

Sofia

{= ${InterfaceData>/contacts/length} === 2}

true

Avoid these common mistakes:

Invalid binding Reason

{/contacts/length}

Reads the previous step’s output, not interface data.

{InterfaceData/contacts/length}

Missing the > that separates the model from the path.

{InterfaceData>contacts/length}

Missing the leading / that starts the path.

{= ${Interface Data>/contacts/length} === 2}

InterfaceData must be written as one word, with no space.

Was this page helpful?

What made the biggest difference for you?
What went wrong? (Your feedback helps us fix it.)

Please don't include personal or sensitive data.