Customizing Service Request Forms

Access through:

Configuration menu > Service Request Configuration > Form Designer tab

Available to:

vCommander Roles of Superuser and Enterprise Admin

About service request forms

vCommander includes default service request forms for New Service Requests and Service Change Requests (these include Decommissioning Requests and Resource Change Requests). In vCommander, you can build customized service request forms from these default forms to better support your existing service request and provisioning process.

New Service Request forms are comprised of two parts:

  • Service-level settings: These settings apply to a service as a whole. Ownership, expiry date, estimated cost, and deployment destination are examples of service-level settings. You can configure these settings in the Form Designer, as detailed in this topic, and when a Service Portal or vCommander user makes a New Service Request, the corresponding labels and fields for those settings will appear in the Service section of the New Service Request dialog that will display.
  • Component settings: Other settings, such as CPU, memory, network and credentials, are component-specific. These are not configured in the Form Designer. Rather you configure these component settings when you create service catalog entries; you must configure at least one component blueprint when you create a new service catalog entry, but you may add multiple components to a service catalog item. The choices you make in the component blueprint forms will determine what appears in the Component section of the New Service Request dialog.

Change Request Forms are comprised of only a component setting part. Decommissioning Requests and Resource Change Requests will be made for services that are already provisioned with specific components. Therefore, the forms for these requests will only be concerned with present information and/or component related options to users. You can configure these component-specific settings in the Form Designer, as detailed in this topic.

If you upgraded from release 5.2 or earlier, all existing service catalog entries use the "legacy" model by default, and any Component forms you customized are still used. If you want to continue to use the legacy model, see Customizing Legacy Service Request Forms instead.

The order of precedence for assignment of service settings during the request process is as follows (the first item in the list takes precedence):

See also

The following Knowledge Base articles provide more information on request forms:

Example: Form Designer output

The following example shows a new service request form that a Service Portal user will see after it's created through the Form Designer in vCommander.

For this example, we added a service called "Developer Service" to the Service Catalog. It contains two components: a VM component called "Windows Server 2008 R2" and a new custom component that we created, called "SQLServer".

When a user requests this service, they see a request form similar to the following:

New Service Request
  • The section labeled "Developer Service" is based on the Default Service form.
  • The section labeled "Windows Server 2008 R2" is based on the Form tab for that component in the Service Catalog's Component Blueprint.
  • The section labeled "SQLServer" is based on the Form tab for that component in the Service Catalog's Component Blueprint.

We can also create non-default forms at the service level and assign them to different users and groups, as shown in the next section.

Creating new forms

To supplement the default service request forms vCommander provides, you can create additional custom forms to assign to different users and groups.

What forms will users see?

When you create custom Service Request forms, the users or groups you specify will see one of the forms  they are assigned rather than the global Default Service form. A user can be assigned only one New Service Request form. However, you can assign any number of Service Change Request forms with a user, and the user will be prompted to select a form when requesting a service change.

Forms are shown to users in the following order of precedence (the first item in the list takes precedence):

  • Forms assigned directly to a user
  • Forms assigned to the user's organization
  • Forms assigned to a user's Directory Services group
  • Otherwise, the global form is displayed

To create a New Service Request form

To create a Service Change Request form

  1. Click Add in the Form Library panel.
  2. In the Add Request Form dialog, enter a form name. This name appears in the Form Library as well as for users making a service request from vCommander. It is not displayed for Service Portal users.
  3. Enter a display name if you want Service Portal users to see a different form name in request emails and in the list of service requests.
  4. If the Form Type menu is displayed, choose New Request Service Form.
  5. Specify who should have access to this form.
    Choose an organization, and enter user or group IDs or email addresses and click Add.
  6. Click OK.

Now you can decide what fields should appear on your form. To configure the form elements, see Designing a form's appearance and content.

You can also select an existing form in the Form Library and click Copy as a shortcut.

  1. Click Add in the Form Library panel.
  2. Enter a form name. This name appears in the Form Library and for users making a service request from vCommander. It is not displayed for Service Portal users.
  3. Enter a display name if you want Service Portal users to see a different form name when they need to choose from multiple forms, in request emails and in the list of service requests.
  4. If the Form Type menu is displayed, choose Change Request Form.
  5. In the Target Type drop-down list, if you want this form to be available for managed systems, select Managed Systems. Otherwise, select Inventory. Forms that target managed systems support a limited number of form elements.
  6. From the Completion Workflow menu, choose a completion workflow that will run once change requests submitted with this form are fulfilled.
    For example, if you're creating a decommissioning request form, associate this request with a decommissioning workflow.
  7. If you want this form to be visible to specific users only, choose Publish - Specific organizations, users and groups.
  8. Choose an organization, and enter user or group IDs or email addresses and click Add.
  9. Click OK.

Now you can decide what fields should appear on your form. To configure the form elements, see Designing a form's appearance and content.

You can also select an existing form in the Form Library and click Copy as a shortcut.

Designing a form's appearance and content

When you select a form in the Form Library panel, its current heading and field elements are displayed in the Form Designer. You can edit these elements, add new elements and change the order in which they are presented.

To modify a selected request form, do any of the following:

  • To modify the parameters displayed in any element, select the element, and click Edit. After you have made your modifications, click OK.
  • If you want a field to be mandatory for users, enable the Required checkbox. In the Form Designer, mandatory fields are marked with an asterisk (*).

  • To add new fields to the form, in the Toolbox at the right side of the window, click the appropriate form element. The element will appear at the bottom of the form.
  • To change the order in which the elements will be displayed in the form, drag-and-drop the elements or use the up and down arrows.

To discard all changes and go back to the last-saved version of the form, click Revert.

To test your form with all services currently in your Service Catalog, click Preview.

When one or more organizations are assigned to the form, the preview is based on the first organization and the first user within that organization (alphabetically). When one or more users or groups are assigned to the form, the preview is based on the first user or group (alphabetically), and if the user is a member of an organization, the preview is also based on the user's first organization (alphabetically). For example, if you have assigned a form to two groups named "Dev" and "Test", you will preview request forms as a member of the group "Dev". When a service contains multiple components, the preview of the Component section of the form is based on the Form tab for the first component (alphabetically).

Adding custom attributes to forms

Note that adding standard elements to the request form (whether service-level or component-level) is only one way that a requested service can be customized.

  • If you want to let your users specify a value for a custom attribute, add the Custom/Placement Attribute element to a service form in the Form Designer, or to the Form tab for a component blueprint.
  • If you don't want user input, add a custom attribute to the Attributes tab in the component blueprint. You can specify a default value if you like, or leave it blank for an administrator to enter during manual deployment.

You can also specify values for the custom attribute during automated deployment by adding a Set Custom Attribute step to a completion workflow.

Additional design considerations

  • If a Service form is empty in the Form Designer, the Service section won't appear in the New Service Request dialog. So, if you don't want your New Service Request dialog to include a Service section, delete all elements from the Service form.
  • Change request forms that contain elements not relevant to the selected service type won't be displayed to users initiating a change request. For example, a form that contains the CPU Count, Memory, Instance Type, Storage or Storage-AWS elements is not available for virtual services, load balancers, stacks, auto scaling groups and databases. We recommend creating one or more Service Change Request forms for non-VM service types that don't include these elements.
  • For New Service Request forms, if you include a custom attribute on both the Service form and the blueprint form and you allow users to set a value on both forms, requesters can override the value set for the service on the blueprint form.
  • You can create relationships between form fields, so that the value selected for one element affects the selectable values for another. See Creating relationships between custom attributes.
  • You can access values from the request form through workflow variables. See Example: Mapping Request Form Fields to Variables.

Editing forms

Selecting a form in the Form Library panel and clicking Edit allows you to:

  • change the form's name
  • specify what users and groups have access to the form. Note that you can't create multiple global Service forms for new requests.
  • associate a completion workflow with a service change request form

You can't change publishing options for the Default Service form for new requests; it's always set to Publish - Global.

Deleting forms

To delete a custom form, select it in the Form Library and click Delete.

You can't delete any of the default forms.

If you upgraded from version 5.2 or earlier, and you delete a non-default component form, components of that type will then use the default component form of that type.

Form elements available for new service requests

The following table provides details on all form elements that you can add to the Service form for new service requests.

Elements in the Form Designer Toolbox for New Service Requests

Standard

Header

Adds heading text to the form.

Text

Adds explanatory text to the form.

Input Text Field

Allows the requester to enter a value, such as a note or a password.

Important: If users will enter a password on the request form, enable Hide User Input. When Hide User Input is enabled:

  • Asterisks (*) are displayed for this field value in the Request Details dialog, emails, and landing pages.
  • The password is stored, encrypted, in the vCommander database.
  • The plain-text password can be accessed either through the approval workflow variable #{request.service.settings.inputField['field name']} or the Settings subvariable inputField['field name']. For example, if you set the Display Label for the Input Text Field to Password, you would access the password in an approval workflow script with the variable #{request.service.settings.inputField['Password']}.
  • If a request containing a password is copied, the password is blanked out.

Required By

The date the requester requires the service.

In the Default Lead Time (in days) field, enter a number if you want a default Required By date to be displayed on the form. Users can adjust this date.

Service / Component Properties

Primary Owner

Allows the requester to specify a primary owner for the service, or, if you enable the Display Only option, simply displays the primary owner on the form.

Custom/Placement Attribute

Allows the requester to specify a value for a custom attribute or placement attribute. Select an attribute from the drop-down list. The (Placement) suffix is used to distinguish placement attributes from custom attributes.

You can click Create New Attribute to configure a new custom attribute or placement attribute. See Using Custom Attributes to Add Infrastructure Metadata or Configuring Attributes for Intelligent Placement for more information.

You can create relationships between custom attributes, so that the value selected for one attribute affects the selectable values for other attributes. See Creating relationships between custom attributes.

All custom attributes that are configured to be available for VMs and virtual services are available for services as well. Note that it's generally best practice not to include the same custom attribute on both the Service form and the blueprint form. If a custom attribute is included on both the Service form and the blueprint form, the Service form takes precedence.

Important: Don't include text-type custom cost attributes on the request form. Including a text-type custom cost attribute allows the requester to specify the cost of the service they are requesting. Rather, include list-type custom cost attributes, so that you can control the values that a requester can specify.

To ensure accurate cost calculations, don't include custom cost attributes on the Service form; include them only on the blueprint form.

Expiry Date

Allows the requester to specify the expiry date for the service.

Allow "Never Expires": Display the Never Expires checkbox on the service request form.

Default lifespan (in days): Controls the default expiry date displayed on the form.

Maximum lifespan (in days): Limits the expiry date the user can specify. If you don't provide a maximum lifespan, the user can choose any expiry date.

Override Cost Period: Display the estimated cost for the entire lifespan of a requested service, rather than for the cost period configured for the Estimated Cost element. When you enable this option, the Lifespan Cost is shown in the service catalog entry details, the shopping cart, the Estimated Cost on the request form, and approval emails. For example, if you configure a default lifespan of 2 years (730 days), the service catalog entry details display the cost for 2 years. On the request form, if the user changes the default expiry date to three years, the three-year lifespan cost is shown.

When you enable this option, you must also enter a value for Default lifespan (in days).

When using lifespan cost, we recommend that you don't enable the Allow "Never Expires" option. If a user adds two services to the shopping cart and sets one to never expire but sets an expiry date for the other, the Estimated Cost label in the shopping cart may be confusing.

Lifespan Label: This label is displayed only in the service catalog entry details. If you enable Override Cost Period, it's a good idea to include the default lifespan in the Lifespan Label. For example, if you configure a default lifespan of two years (730 days), enter "Lifespan Cost for 2 Years" in the Lifespan Label field.

Quantity

Allows the requester to request multiple identical services more easily. Also allows you to limit the number of each service that can be requested.

Don't include the Quantity form element when vCommander is in single-service request mode, because in this mode, Quantity simply displays "1" for a value, rather than allowing users to select a number.

Estimated Cost

Displays the estimated annual, quarterly or monthly cost for a VM or virtual service.

If the Override Cost Period option is enabled for the Expiry Date element, the Lifespan Cost is displayed on the form instead of the Estimated Cost.

Destination

Allows the requester to specify the deployment destination.

Presents all of the deployment destinations available to this user and valid for the requested service.

Service Catalog costs are updated to reflect the selected destination, so that requesters can understand the cost impact of their decision. Automated deployment proceeds as if only the selected destination is available.

If a user belongs to multiple groups, only the most specific assignment is used, with the following order of precedence:

  1. Destinations assigned directly to this user.
  2. Destinations assigned to a group where the user is a direct member.
  3. Destinations assigned to a parent group (that is, a parent group of a group where this user is a direct member).

This rule ensures that you can control what destinations users will see. For example, if a destination is assigned to a parent group, but not to a child group, a member of the child group will only see that destination if that user has no more specific assignments (numbers 1 and 2 in the order of precedence).

When a user selects Let the system decide and multiple destinations are available to the user for the selected service, the destination with the highest rating is displayed as the expected destination, right under the drop-down menu. If only one destination is available to the user, the control displays a read-only field instead of a drop-down menu. When no destinations are available to the user, Let the system decide is selected.

If you don't make this element mandatory, the default selection on the form is Let the system decide.

If you make this element mandatory, the option Let the system decide is removed from the list of selectable options for requesters, and you must choose from the following options:

  • Force Selection: The Destination menu is blank by default, so the user must select a destination.
  • Provide Default: The best-suited destination is preselected in the Destination menu, so the user can accept this default without making a selection.

If this element is non-mandatory and the user selects Let the system decide, vCommander recalculates the target destination based on the user's storage tier and network zone selections on the component blueprint form.

If you add this element to the Service form and enable the Limit Selections option, the storage tiers and network zones configured for the selected deployment destination are shown on the form, rather than those you configured for the Storage element and the Network element. The Limit Selections option ensures that users don't select a storage tier or network zone that is unavailable on the target destination. The Storage element and the Network element appear on the blueprint form, which you configure in the Service Catalog.

A star rating is displayed for each valid destination for the requested service. Users can click an Information icon to understand how each destination is rated for quota, cost and preferred placement attribute values. A rating of 100 translates into a 5-star rating; a rating of 80 translates into a 4-star rating, and so on. See How Intelligent Placement Works to learn more.

Multi-Select

Allows the requester to select multiple values for a custom attribute. Use this form element to add any list-type custom attribute that is configured to apply only to forms.

This element works only with form attributes, so the values selected on the form are not applied as metadata on deployed services. Therefore, you should use this element only when you need users to be able to multi-select values on the form, but you don't need the metadata to be applied on deployed services. Use the regular Custom/Placement Attribute form element for metadata that persists on deployed services.

You can click Create New Attribute to configure a new custom attribute. See Creating and editing custom attributes for more information.

To allow users to multi-select values, enable Select Multiple.

Form elements available for service change requests

The following table provides details on all form elements that you can add to service change request forms.

Elements in the Form Designer Toolbox for Change Requests

Standard

Header

Adds heading text to the form.

Text

Adds explanatory text to the form.

Input Text Field

Allows the requester to enter a value, such as a note or a password.

Important: If users will enter a password on the request form, enable Hide User Input. When Hide User Input is enabled:

  • Asterisks (*) are displayed for this field value in the Request Details dialog, emails, and landing pages.
  • The password is stored, encrypted, in the vCommander database.
  • The plain-text password can be accessed either through the approval workflow variable #{request.service.settings.inputField['field name']} or the Settings subvariable inputField['field name']. For example, if you set the Display Label for the Input Text Field to Password, you would access the password in an approval workflow script with the variable #{request.service.settings.inputField['Password']}.
  • If a request containing a password is copied, the password is blanked out.

Required By

The date the requester requires the service.

In the Default Lead Time (in days) field, you can enter a number if you want a default Required By date to be displayed on the form. Users can adjust this date.

File Upload

Allows the requester to upload files during the service request process. Uploaded files are added to the VM's local directory as configured in the completion workflow using the Copy Uploaded File workflow step.

Service / Component Properties

Primary Owner

(not available for Managed System forms)

Allows the requester to specify a primary owner for the service / component, or, if you enable the Display Only option, simply displays the primary owner on the form.

Select one of the following allowed actions:

  • Add as new Primary Owner
  • Replace existing Primary Owner
  • Replace all existing owners

Organization

(not available for Managed System forms)

Allows the requester to assign the component to another organization example, to free up quota, or to transfer a VM from the testing organization to the development organization as part of bug detection and resolution.

In the Visibility drop-down menu, select one of the following to control what organizations the requester will be able to choose from:

  • All Organizations
  • Requester's Organizations
  • Custom list - choose one or more organizations from the list that users can select from

To ensure that the service is visible to the primary owner, the primary owner must be a member of the selected organization. If the primary owner is not a member of the selected organization, the error "Primary owner is not a member of the selected organization" error appears in approval emails, approval landing pages, and the Request Details dialog. When manually approving requests, approvers can use the $ORGANIZATION deployment parameter to assign an organization. If multiple organizations are available, approvers can also use the Organization drop-down menu on the approval landing page. Administrators can also change the target organization in the Fulfill Request dialog.

Custom/Placement Attribute

Allows the requester to specify a value for a custom attribute or placement attribute. Select an attribute from the drop-down list. The (Placement) suffix is used to distinguish placement attributes from custom attributes.

You can click Create New Attribute to configure a new custom attribute or placement attribute. See Using Custom Attributes to Add Infrastructure Metadata or Configuring Attributes for Intelligent Placement for more information.

You can create relationships between custom attributes, so that the value selected for one attribute affects the selectable values for other attributes. See Creating relationships between custom attributes.

Expiry Date

(not available for Managed System forms)

Allows the requester to extend the expiry date of a VM.

Another way to allow VM expiry extension is through the Expiry Extension setting in the Expiry policy.

Allow "Never Expires": Display the Never Expires checkbox on the service request form.

Component Name

(not available for Managed System forms)

Allows the requester to change the display name of a VM component. See also About service naming.

Schedule

Allows the requester to specify when a change request will be fulfilled. All parts of a change request are fulfilled at the same time. The Schedule form element takes precedence over the automation options in the approval workflow.

Select one or more allowed options from the drop-down menu:

  • Immediately: Changes are fulfilled immediately after approval.
  • In Maintenance Window: Changes are fulfilled during the next maintenance window.

If the approval process is not complete before the next maintenance window begins, the changes are automatically rescheduled for the next maintenance window.

Specific Time: Changes are fulfilled at the specified time.

If the approval process is not complete before the specified time, the changes won't be fulfilled. The request state will be "Failed", and a comment will appear in the Request Details in red, indicating that the request was not fulfilled. An administrator must manually fulfill the request in this case.

After the request is approved, a scheduled task is created. The requester will be able to see and delete this scheduled task if necessary.

Resources

Instance Type

(not available for Managed System forms)

Allows the requester to change the instance type for an Amazon EC2 VM. The requester can select only instance types that are compatible with the current instance type. The requester can also set the EBS Optimized flag on the form if the selected  instance type supports it.

CPU Count

(not available for Managed System forms)

Allows the requester to specify or change CPU count requirements for a VM component. You can limit the number of CPUs that users can request by entering a comma-separated list of values (for example, 1,2,4).

This element is not displayed on public cloud component forms, because the CPU count is determined by the selected instance type and can't be changed.

Memory

(not available for Managed System forms)

Allows the requester to specify or change memory requirements for a VM component. You can limit the amount of memory that users can request.

This element is not displayed on public cloud VM component forms, because the memory is determined by the selected instance type and can't be changed.

Storage

(not available for Managed System forms)

Allows the requester to change storage requirements for a VM or virtual service component on vCenter or SCVMM. The selectable storage tier values can be customized.

You must ensure that datastores are available to back all storage tiers in use.

It's not possible to resize IDE disks, independent disks, or disks involved in a snapshot or linked clone chain.

Allowed Actions: Specify whether the requester can Add disks, Change disks, and Remove disks.

If you specify that the user can change existing disks, specify the Maximum Disk Size.

If you specify that the user can both add and change disks, specify the Maximum Disk Size and Maximum Extra Disks.

Storage - AWS

(not available for Managed System forms)

Allows the requester to change storage requirements for an Amazon EC2 VM. This form element is displayed on forms for AWS services; the Storage form element is not displayed.

Selectable Disk Types:

  • General Purpose (SSD): General purpose Solid-State Drive volume that balances price and performance for a wide variety of transactional workloads. Recommended for system boot volumes, virtual desktops, low-latency interactive apps, development and test environments.
  • Provisioned IOPS (SSD): Highest-performance SSD volume designed for mission-critical applications. Best for critical business applications that require sustained IOPS performance, or more than 10,000 IOPS or 160 MiB/s of throughput per volume, such as large database workloads and EBS-optimized instances. The ratio of IOPS provisioned and the volume size requested can be a maximum of 50.
  • Magnetic: Previous-generation Hard Disk Drive volumes for workloads where data is infrequently accessed. Not recommended for new applications.
  • Throughput Optimized (HDD): Low-cost Hard Disk Drive volume designed for frequently accessed, throughput-intensive workloads. Best for streaming workloads requiring consistent, fast throughput at a low price, such as big data, data warehouses, and log processing. The minimum disk size for this type is 500 GB. can't be a boot volume.
  • Cold (HDD): Lowest-cost Hard Disk Drive volume designed for less frequently accessed workloads. Best for throughput-oriented storage for large amounts of data that is infrequently accessed. The minimum disk size for this type is 500 GB. can't be a boot volume.

Allowed Actions: Specify whether the requester can Add disks, Change disks, and Remove disks.

If you specify that the user can add disks:

  • specify the Maximum Disk Size and Maximum Extra Disks
  • specify whether new disks will be encrypted by default with the Encryption option
  • specify whether new disks will be deleted on termination by default with the Delete on Termination option

If you specify that the user can change disks:

  • specify the Maximum Disk Size
  • specify whether new disks will be encrypted by default with the Encryption option
  • specify whether new disks will be deleted on termination by default with the Delete on Termination option

Storage - Azure

(not available for Managed System forms)

Allows the requester to change storage requirements for an Azure VM. This form element is displayed on forms for Azure services; the Storage form element is not displayed.

Storage Types: Select Managed and/or Unmanaged as required.

Selectable Disk Types: If you selected Managed in the Storage Types list, you can select one or both of the following disk types:

  • SSD: Premium disks (SSD) are backed by solid-state drives and offer consistent, low-latency performance. They provide the best balance between price and performance, and are ideal for I/O-intensive applications and production workloads. Premium disks are not supported for all instance types.
  • HDD: Standard disks (HDD) are backed by magnetic drives and are preferable for applications where data is accessed infrequently.

Display Storage Tier: If you selected Unmanaged in the Storage Types list, you can specify whether the user can select a storage tier.

Selectable Tiers: If you selected Unmanaged in the Storage Types list, and you enabled Display Storage Tier, select storage tiers to make them available on the form.

Allowed Actions: Specify whether the requester can Add disks, Change disks, and Remove disks.

If you specify that the user can add disks, specify the Maximum Disk Size and Maximum Extra Disks.

If you specify that the user can change disks, specify the Maximum Disk Size.

vCommander chooses the datastore for new unmanaged disks using the following order of precedence:

  • All disks in the target region with the requested storage tier are sorted alphabetically. If there are no matches, the task fails.
  • Next, for any of the deployment destinations that target the VM's resource group, vCommander searches for datastores targeted by those deployment destinations, and chooses the first alphabetically.
  • Next, for any of the deployment destinations that are assigned to the user and/or the user's organization, vCommander searches for datastores targeted by those deployment destinations, and chooses the first alphabetically.
  • Next, vCommander searches for datastores belonging to the VM's resource group, and chooses the first alphabetically.
  • If none of these criteria generates a match, the task fails.

Estimated Cost

(not available for Managed System forms)

Displays the estimated annual, quarterly or monthly cost for a service.