VCF Operations Orchestrator: Why I Write Actions and Not Workflows (Mostly)

This might be a controversial stance, but if you’ve reviewed any of my VCF Operations Orchestrator code, you’ll notice that 99% of it is written as Actions. I take this approach because it enables me to write “pure” JavaScript code that is easier to read, maintain, and integrate with modern development tools such as linters, unit testing frameworks, and code analysers.

Workflows are a visual tool that provides a drag-and-drop interface used to develop automation flows without writing (much) code. It was originally intended for system administrators and infrastructure teams, who might not be traditional developers, to automate tasks on vCenter Server.

Below is an example of a very simple Workflow with small script tasks, a for each loop and some error handling (red line).

The challenge is that the landscape has evolved significantly since Orchestrator was first released in 2009. What began as a platform for simple scripts and automation flows has grown into a tool expected to support complex solutions, often requiring integration with dozens of disparate systems.

This has led to a significant challenge: developers are still attempting to build automation using Orchestrator’s traditional workflow-based model. In my view, this approach is no longer suitable, as workflows have grown so large and complex that they’ve become increasingly difficult to maintain, understand, and troubleshoot.

Let’s take a look at another Workflow example that is used to run a script on a virtual machine.

While this is a relatively clean example (and I’ve seen far worse), it serves to illustrate what a large Workflow can look like. At first glance, it may appear manageable, but once you need to make changes, you’ll likely spend more time wrestling with the visual layout than making meaningful progress. The complexity of the visual interface quickly becomes a barrier to efficient development.

There’s another significant issue: workflows are primarily stored as XML. When versioned in a Git repository, you’re essentially working with raw XML files. This makes development outside of the visual editor extremely cumbersome and complicates peer reviews as merge requests become difficult to read, understand, and evaluate effectively.

Here is an example of a Workflow in XML format, which can often be several hundred, if not thousands, of lines long.

In conclusion, Orchestrator’s traditional workflow-based development model no longer aligns with the demands of modern automation. As automation solutions grow in complexity and scale, the limitations of this approach become increasingly clear.

My solution is simple: write Actions. By focusing on Actions, you gain the flexibility to write clean, modular JavaScript code that is easier to maintain, test, and integrate with modern development practices and tooling.

Unfortunately, it’s not possible to eliminate Workflows entirely; for example, VCF Automation Extensibility Subscriptions require a workflow as the entry point. However, it’s entirely feasible to significantly reduce reliance on workflows by offloading most of the logic into reusable Actions.

I address this limitation by placing only a single Action on the workflow palette. If you think of a workflow as a top-level function, then that role can just as effectively be filled by an Action. This Action can serve as the entry point, chaining together other Actions and consuming other services, while keeping the visual workflow minimal and maintainable.

The resulting Workflow looks like this (all my workflows follow this pattern)

and the corresponding XML:

This structure is largely static and easily templated if needed. The only elements that typically require modification are the input parameters, output parameters, and the referenced Action, everything else remains consistent.

Another major advantage of writing Actions is the ability to leverage a broader development ecosystem. When using the Build Tools for VMware Aria, Actions become easy to develop and maintain, while also unlocking powerful capabilities such as unit testing, linting, static analysis, and full integration with your preferred IDE.

If you’re an Orchestrator developer, I’d love to hear your perspective. What approaches have you taken to modernize your development practices on the platform?

Let’s share ideas and learn from each other’s experiences!