An important limitation of the XaaS components used in the cloud template designer is that, being custom resources-based, it must provision a custom component. This is different from vRealize Automation 7.x where the service can start any workflow, even if it was not outputting a custom resource.

If your environment includes vRealize Automation 7.x blueprints components that are, for example, implementing some configuration changes, it will be necessary to use other means to trigger this workflow. The alternative is to use Event Broker to do so.

Another area that is very different in VMware Aria Automation 8.x is the way that these components inputs and outputs can be bound to other components on the schema. In vRealize Automation 7.x, these bindings only supported simple types and were controlled through the user interface without any program based approach. In VMware Aria Automation 8.x, the Create workflow inputs define the properties in the YAML schema and these can be scripted. These inputs can be mapped to the cloud template input properties even if these are of complex types. With this you can, for example, use an input of a given resource type that can be searched.