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

Embotics® vCommander® includes several default service request forms for New Service Requests, Decommissioning Requests and Resource Change Requests. You can build any number of service request forms and any number of change request forms that support your existing service request and provisioning process.

New Service Request forms have two parts: service and component

Some form settings apply to the service as a whole, and you configure these in the Form Designer, as detailed in this article. Placement destination, ownership and expiry date are examples of service-level settings. Service forms are assigned to users and groups.

Other settings, such as CPU, memory, network and credentials, are component-specific; you configure the component blueprint when you create the service catalog entry.

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

Note that adding elements to the request form (whether service-level or component-level) is only one way that a requested service can be customized. For example, if you want to let your users specify a value for a custom attribute, add the Custom 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.

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

Settings specified during manual deployment of a requested VM or virtual service, OR settings specified in a completion workflow through a Lifecycle Management workflow step

Deployment parameters specified in an approval workflow script, or by an approver through the approval comments are assigned

Information specified by a user on the request form

Settings specified in the service catalog entry

Accessing form field values with workflow variables

You can access values from the request form through workflow variables. See Example: Mapping Request Form Fields to Variables.

Form fields that are dependent on other form field values

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.

See also

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

Choosing Approvers Based on Request Form Used

Automating Self-Service Decommissioning

Example: New service request forms

To help you understand how request forms work, here's an example. We created a custom component type called SQLServer.

We added a service called Developer Service to our Service Catalog. It contains two components: a VM component named Windows Server 2008 R2 and the new custom component, SQLServer.

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

request-new-service-form

The first section, labeled "Developer Service", is based on the Default Service form.

The second section, labeled "Windows Server 2008 R2", is based on the Form tab for this component in the service catalog blueprint.

The third section, labeled "SQLServer", is based on the Form tab for this component in the service catalog 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 a new form

You can create additional forms so that you can assign different forms to different users and groups.

If you create additional Service forms for new requests, the users or groups you specify will see this form rather than the global Default Service form. A user can be associated with only one service-level form.

By contrast, you can associate any number of Service Change Request forms with a user. The user is prompted to select the form when requesting a service change.

To create a new form, click Add in the Form Library panel, and follow the instructions in the table below. You can also select an existing form in the Form Library and click Copy as a shortcut.

NotePencil-smallDepending on how you access the Edit Request Form dialog, some fields may be grayed out. For example, if you copy an existing Service form, the Form Type drop-down menu is preselected and grayed out.

To create a New Service Request form

To create a Service Change Request form

1.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.

2.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.

3.If the Form Type drop-down menu is displayed, select New Request Service Form.

4.Specify who should have access to this form. Choose an organization, and enter user or group IDs or email addresses and click Add.

1.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.

2.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.

3.If the Form Type drop-down menu is displayed, select Change Request Form.

4.In the Completion Workflow drop-down menu, choose a completion workflow that will run once change requests submitted with this form are fulfilled. For example, if you are creating a decommissioning request form, associate this request with a decommissioning workflow.

5.If you want this form to be visible to specific users only, select Publish - Specific organizations, users and groups.

6.Choose an organization, and enter user or group IDs or email addresses and click Add.

Order of Precedence for Form Assignment

Forms are shown 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

Now you can decide what fields should appear on your form.

Designing a form's appearance and content

Selecting a form in the Form Library panel displays the form's fields in the Design panel.

New Service Request forms are designed in two parts:

a Service form (designed in the Form Designer) defines what appears in the Service section of the New Service Request dialog

a component blueprint form (designed in the service catalog) defines what appears in the Component section of the New Service Request dialog.

Service Change Request forms have only a single section and are designed entirely in the Form Designer.

The form designer is used to:

change the text and style of form headings

add new fields to a form by clicking an element from the Toolbox

change the order of the elements using drag-and-drop or the up and down arrows

specify mandatory fields with the Required checkbox; mandatory fields are marked with an asterisk (*)

Clicking Revert discards all changes from the last-saved version.

Clicking Preview allows you to test your form with all services currently in your Service Catalog. When you have assigned one or more organizations to the form, the preview is based on the first organization and the first user within that organization (alphabetically). When you have assigned one or more users or groups 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).

Notes

If a Service form is empty, the Service section does not appear in the New Service Request dialog. So, if you do not want your New Service Request dialog to include a Service section, just delete all elements from the Service form.

Change request forms that contain elements which are not relevant to the selected service type are not 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 do not 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. For example:

override_value_from_service_form

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.

Table: 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 Attribute

Allows the requester to specify a custom attribute value.

You can click Create New Attribute to configure a new custom attribute. See Using Custom Attributes to Add Infrastructure Metadata 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: Do not 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, do not 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.

NotePencil-smallWhen you enable this option, you must also enter a value for Default lifespan (in days).
NotePencil-smallWhen using lifespan cost, we recommend that you do not 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.

NotePencil-smallDo not 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.

NotePencil-smallIf 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 on the managed system hosting the requested service. For public cloud, this element presents all deployment destinations valid for the user that are in the same region as the source image.

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 capacity (or, for public cloud, the first alphabetical destination) 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 do not 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 drop-down menu is blank by default, so the user must select a destination.

Provide Default: The best-suited destination is preselected in the Destination drop-down 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 do not 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.

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 do not need the metadata to be applied on deployed services. Use the regular Custom Attribute form element for metadata that persists on deployed services.

You can click Create New Attribute to configure a new custom attribute. See Using Custom Attributes to Add Infrastructure Metadata 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.

Table: 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.

Service / Component Properties

Primary Owner

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

Allows the requester to assign the component to another organization—for 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 Attribute

Allows the requester to specify a custom attribute value.

You can click Create New Attribute to configure a new custom attribute. See Using Custom Attributes to Add Infrastructure Metadata 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

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

NotePencil-smallAnother 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

Allows the requester to change the display name of a VM component. See also About VM and Virtual 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.

NotePencil-smallIf 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.

NotePencil-smallIf the approval process is not complete before the specified time, the changes will not 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

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

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 cannot be changed.

Memory

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 cannot be changed.

Storage

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

NotePencil-smallYou must ensure that datastores are available to back all storage tiers in use.

For AWS, the Storage-AWS form element is displayed instead. Storage requirements cannot be changed for Microsoft Azure VMs.

NotePencil-smallIt'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

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. Cannot 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. Cannot 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-ARM

Allows the requester to change storage requirements for an Azure Resource Manager VM. This form element is displayed on forms for ARM 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

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

Changing a form's name, publishing options and associated workflow

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 cannot have multiple global New Service Request forms of the same type (for example, multiple global VM component forms).

associate a completion workflow with a service change request form

NotePencil-smallYou cannot change publishing options for the default New Service Request forms.

Deleting a form

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

You cannot delete any of the default forms.

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