vRO 7.6 XaaS form support clarification

When vRealize Orchestrator 7.6 became generally available last week (and related to the simultaneous availability of vRealize Automation 7.6), an eagle-eyed VMware Partner spotted a statement in the release notes under the Feature and Support Notice section.

One of the statements in that section initially read:

vRealize Automation XAAS forms support only workflows created in the Orchestrator Legacy Client.

I asked a colleague in the Cloud Management Business Unit (CMBU) about this and was eventually put in touch with the right person in R&D who could expand on the meaning further.

The statement has now been adjusted to read:

The input parameter constraints of workflows created or edited in the vRealize Orchestrator Client do not automatically transfer to the XaaS blueprint request form in vRealize Automation. When using these workflows in XaaS operations, you must manually define the input parameters constraints in the XaaS blueprint request form. This limitation does not impact workflows created and edited exclusively in the Orchestrator Legacy Client.

It is important to note that in vRO 7.6, the term “vRealize Orchestrator Client” refers to the new HTML5 web client, whereas the term “vRealize Orchestrator Legacy Client” is used to describe the Java client that anyone used to vRO knows very well! In case you haven't yet seen the new HTML5 client for vRO, I have a screenshot of it in my posting on the availability of vRA 7.6, and I'll paste it here too.

Going back to the clarification, it means that workflows that are created / edited in the new client interface will not automatically have their presentation settings imported when adding the workflow as a XaaS blueprint or when refreshing the form design. Instead, a custom form would have to be created. The functionality is unaffected when using the legacy (Java) client.