7.1

Designing Forms for XaaS Blueprints and Actions
The XaaS includes a form designer that you can use to design submission and details forms for blueprints
and resources actions. Based on the presentation of the workows, the form designer dynamically generates
default forms and elds you can use to modify the default forms.
You can create interactive forms that the users can complete for submission of catalog items and resource
actions. You can also create read-only forms that dene what information the users can see on the details
view for a catalog item or a provisioned resource.
As you create XaaS custom resources, XaaS blueprints, and resource actions, forms are generated for
common use cases.
Table 11. XaaS Object Types and Associated Forms
Object Type Default Form Additional Forms
Custom resource Resource details form based on the
aributes of the vRealize Orchestrator
plug-in inventory type (read-only).
n
None
XaaS blueprint Request submission form based on the
presentation of the selected workow.
n
Catalog item details (read-only)
n
Submied request details (read-only)
Resource action Action submission form based on the
presentation of the selected workow.
n
Submied action details (read-only)
You can modify the default forms and design new forms. You can drag elds to add and reorder them on
the form. You can place constraints on the values of certain elds, specify default values, or provide
instructional text for the end user who is completing the form.
Because of their dierent purposes, the operations you can perform to design read-only forms are limited
compared to the operations for designing submission forms.
Common Components
vRealize Automation includes several common components in addition to the service catalog and catalog
item sources such as Infrastructure as a Service and XaaS.
Notifications
You can send automatic notications for several types of events, such as the successful completion of a
catalog request or a required approval.
System administrators can congure global email servers that process email notications. Tenant
administrators can override the system default servers, or add their own servers if no global servers are
specied.
Tenant administrators select which events cause notications to be sent to users in their tenants. Each
component, such as the service catalog or IaaS, can dene events that can trigger notications, but none of
them are selected by default.
Each user can choose whether to receive notications. Users either receive all notications congured by the
tenant administrator or no notications, they do not have ne-grained control over which notications to
receive.
Some emails have links that users can use to respond to the notication. For example, a notication about a
request that requires approval can have one link for approving the request and one for rejecting it. When a
user clicks one of the links, a new email opens with content that is automatically generated. The user can
send the email to complete the approval.
Foundations and Concepts
VMware, Inc. 33