Workflow Design: IN/OUT Bindings & Decision Elements

Most vRO bugs announce themselves. A failed REST call produces a stack trace. A vCenter permissions error turns an element red. These are easy — loud and fast to fix.

The hard bugs complete green and produce wrong results. A variable that should have a value is null. A branch that should have fired didn't. The workflow did exactly what you told it to do — you just didn't tell it what you meant.

Two mechanisms produce this failure mode more than anything else: variable bindings and Decision elements. Neither throws an error when misconfigured. Both fail silently and let the workflow keep running.

vRO has three variable scopes, and conflating them is where most binding mistakes start.

Workflow Inputs are supplied by the caller and available everywhere in the workflow. You do not declare them as IN bindings on individual elements — they're already there.

Workflow Variables are the workflow's internal state. They persist across elements, but a Scriptable Task that reads a workflow variable without declaring it as an IN binding doesn't get the current value — it gets null. Same in reverse: a value computed inside a script only survives past that element if it's written to a workflow variable through an OUT binding.

Local script variables (var x = ...) exist only for the duration of that script. When the element completes, they're gone.

1. actionResult Not Mapped to a Workflow Variable

An Action returns a value. No OUT binding is configured. The return value is discarded silently. Downstream elements get null, and the error surfaces several steps later — far from the actual mistake.

Fix: every Action element that returns a value needs actionResult → a named workflow variable in its OUT bindings.

2. Scriptable Task Reads a Variable With No IN Binding

The script looks correct — the variable name is right, the logic is right. But the binding panel doesn't declare it as an IN. At runtime it resolves to null, not the current workflow value.

Fix: every workflow variable a Scriptable Task reads must be in its IN bindings.

3. Workflow Input Re-declared as a Scriptable Task OUT Binding

Workflow Inputs are available throughout the workflow without binding. If one appears in a Scriptable Task's OUT list and the script never assigns it, vRO writes null to it when the task completes — overwriting the original input value for every element that follows.

Fix: Workflow Inputs are never OUT bindings.

4. Action Parameters Are Set Inside the Action — Not in the Schema

This one catches people the first time. When you add an Action element to a workflow and open its IN binding panel, you're mapping workflow variables to the Action's declared input parameters. You cannot add, remove, or rename those parameters from the schema. That has to be done inside the Action editor itself — once changed there, the updated signature appears in the workflow's binding panel.

5. Action Parameter Name Mismatch After Refactoring

Rename a parameter inside an Action without updating the bindings in every workflow that calls it and those bindings silently receive null. No error — the parameter just isn't there.

Fix: when renaming Action parameters, audit every calling workflow and update bindings to match.

A Decision element is a schema-level branch. It evaluates a single boolean expression and routes the workflow down a yes or no path. No script body — just a condition and two connectors.

This is the correct way to handle control flow in vRO. Not if/else inside a Scriptable Task — a Decision element in the schema, visible to anyone reading the workflow diagram, with explicit paths wired to the next elements.

The standard pattern is a null-check after a lookup:

If the resource wasn't found, the workflow terminates cleanly — not with a null reference error three elements later.

Decision conditions should stay simple. A few examples:

JavaScriptvmRecord != null
deleteStatus == "Accepted"
ipAddress != null && ipAddress != ""

If the condition requires real logic to evaluate, it doesn't belong in the Decision expression — that's what the boolean flag pattern is for.

When a branching condition is more complex than a null-check, compute it first.

A thin Scriptable Task runs before the Decision element. Its only job is to evaluate the condition and write a boolean to a workflow variable. The Decision branches on that single variable — no compound logic in the expression.

JavaScript// Scriptable Task: EvaluateReadiness
// IN:  vmRecord, deleteStatus, lockOverride
// OUT: readyToDelete (Boolean)

var statusOk   = (deleteStatus == "Approved");
var recordOk   = (vmRecord != null);
var overrideOk = (lockOverride == true || statusOk);

readyToDelete = recordOk && overrideOk;

Decision condition:

JavaScriptreadyToDelete == true

The schema stays readable. The logic is in one named place. The resolved value of readyToDelete is visible in the execution log — something a compound Decision expression can't give you.

• Bindings are explicit, always. Missing an IN binding passes null. Missing an OUT binding discards the result. Neither produces an error.
• actionResult must be mapped. If an Action's OUT binding is missing, the return value is gone.
• Workflow Inputs are never OUT bindings. Putting one in a Scriptable Task's OUT list will null it out on completion.
• Action parameters are defined inside the Action. You can't modify the parameter signature from the workflow schema — go into the Action editor, make the change, then return to wire the binding.
• Decision elements belong in the schema. Branching logic that determines which element runs next should be visible in the diagram, not buried in a script.
• Compute complex conditions before branching. A boolean flag from a thin Scriptable Task keeps Decision conditions simple and keeps logic auditable.