Automatically Log Task and Action Names in Big Workflows

Orchestrator workflows can get huge for big jobs like hardware deployments or tenant provisioning, and they often call other workflows too. When one of them fails, finding the exact scriptable task that broke can take a while. Here’s a small logging habit that helps, and a trick that keeps the log messages correct even when you rename your tasks.

Tested on: VCF Operations Orchestrator 9.1.1 (Nov 2026) and vRealize Orchestrator 8.x (original post, 2022).

The problem

For debugging, most of us rely on System.log() or System.debug() to see what happened up to a point. I go one step further and log a start and an end message in every scriptable task. If a task starts but never logs its end message, I know exactly where the workflow broke.

For example, in a Create a VM workflow with a scriptable task called Get All VM Names, I’d add this at the top of the script:

System.log("\"Get All VM Names\" script started");

And this at the end:

System.log("\"Get All VM Names\" script completed");

This really helps in a big workflow, but it has one annoying problem. When you change what a task does and rename it, say from Get All VM Names to Get All VM Names and IPs, you also have to update both log lines. And that’s easy to forget.

The solution

I found a neat way around this on the VMware community forum: System.currentWorkflowItem() returns the item that’s running right now, so the script can read its own name.

In scriptable tasks

System.log("\"" + System.currentWorkflowItem().getDisplayName() + "\" script started");
System.log("\"" + System.currentWorkflowItem().getDisplayName() + "\" script completed");

This always logs the current name of the scriptable task, so you can rename it as often as you like.

If you also want the item number (like item1), use this:

System.currentWorkflowItem().getName();

In actions (optional)

This one is a little tricky. An action doesn’t have its own name on the canvas, but when you add it to a workflow, it becomes an item with a name and an item number. So the same trick logs the name of the workflow item that called the action:

if (System.currentWorkflowItem().getDisplayName())
    System.log("\"" + System.currentWorkflowItem().getDisplayName() + "\" action started");
if (System.currentWorkflowItem().getDisplayName())
    System.log("\"" + System.currentWorkflowItem().getDisplayName() + "\" action ended");

The if check is there for when you run the action on its own. Then there’s no workflow item, the display name is empty, and nothing is logged, instead of a confusing "" action started.

Extras

A few more ways to get details about the workflow from inside a script. I ran these on 9.1.1 and fixed a couple of lines from the original version that no longer return anything:

System.log("Workflow name: " + workflow.currentWorkflow.name);
System.log("Token name: " + workflow.name);
System.log("Root workflow name: " + workflow.rootWorkflow.name); // differs from currentWorkflow in nested workflows
var wfInstance = Server.getWorkflowWithId(workflow.currentWorkflow.id);
System.log("Path: " + wfInstance.workflowCategory.path + "/" + wfInstance.name);
System.log("Current item: " + System.currentWorkflowItem().getName()); // item1
System.log("First item: " + wfInstance.firstItem);

System.log("*** List of items in the workflow");
for (var i = 0; i < wfInstance.items.length; i++) {
    System.log(wfInstance.items[i].name); // End, Get All VM Names, ...
}

System.log("*** List of attributes in the workflow");
for (var j = 0; j < wfInstance.attributes.length; j++) {
    System.log(wfInstance.attributes[j].name);
}

Things to watch out for

• Spelling matters. It’s firstItem, not firstitem. The lowercase version just returns undefined, with no error.
• Call it as a function. System.currentWorkflowItem without the brackets doesn’t give you the item, so System.currentWorkflowItem.itemName is always undefined.
• Nested workflows. workflow.currentWorkflow is the workflow that’s running the script, while workflow.rootWorkflow is the one at the top. In a simple workflow, they’re the same.

Wrapping up

It’s a tiny change, but with start and end messages in every task, a failed run in a big workflow points you straight to the right place, and renaming tasks no longer breaks your logs. See you in the next post.