Workflow Steps Reference
This topic provides details on Commander's built-in workflow steps. Administrators can always access built-in steps in any Commander installation.
Note: Commander also supports plug-in workflow steps that you may download and install as required. Plug-in steps are not covered here. For details on plug-in steps, see the readme files included with the plug-in step JAR files added to your system at
<Commander_install_directory>\tomcat\wfplugins\. See Using Plug-In Workflow Steps.
In this topic:
The steps that can be added to a workflow depend on the type of workflow. For example, in the Approval Workflow, Completion Workflow, and Command Workflow wizards, the executable steps, or actions, that can be added a workflow depend on:
- the type of workflow (for example, whether it's a workflow for a virtual service versus a VM, or a workflow for a new request versus a change request)
- the cloud account type (for example, SCVMM or AWS)
Adding actions to a workflow is optional. For some scenarios it may make sense to create a workflow without actions. For example:
- You can set up an approval and pre-provisioning workflow whose only purpose is to deploy VMs and virtual services automatically.
- You can set up a completion workflow that overrides a default completion workflow. For example, let's say you have set up a default VM completion workflow to run every time a new VM is provisioned, but you don't want that workflow to run on one or more specific VMs. In this case, you can configure a VM completion workflow that contains no steps — its only purpose is to override the default VM completion workflow.
These steps are supported for all service types.
You can specify that the value returned by the script be captured as a comment, thus determining whether the request is approved or rejected. When you capture script output as comment, you can use script output as the input to a subsequent Set Custom Attribute step. See Using Script Output as Input to a Workflow Step. Scripts in approval workflows can also set deployment parameters.
Note: When configuring the command line for script steps (with the exception of an Execute Embedded Script), you must use an absolute path to the executable.
For script syntax, see Variable Syntax for Emails and Scripts.
These steps are supported for all service types.
These steps allow you to customize a VM after deployment. For examples, see Automating VM Customization through Workflows: Examples. For troubleshooting, see Troubleshooting and auditing Guest OS workflow steps. These steps are supported for VMs only.
Note: If the Dynamic Resource Scheduling (DRS) automation level for a cluster is set to Fully Automated and VM-level DRS control is allowed, Commander temporarily disables DRS during post-deployment configuration for new VMs deployed into the cluster. Disabling DRS ensures that vSphere won't migrate a newly provisioned VM before customization is complete. DRS is re-enabled once the service is completed or the request is rejected. A Commander event is generated for the cluster when DRS is disabled, and again when it's re-enabled. This feature is supported for VMware 4.0 or higher.
Using a workflow step to set metadata for a service can be a convenient shortcut. To ensure that the proper values are set, it's best practice to set metadata through policy or through a completion workflow, not both. The metadata values that are applied last are those that take effect. These steps are supported for all service types.
In any workflow step that sends an email, in the Address List field, enter the email account(s) to which you want any emails sent in the order you want them sent (multiple email accounts must be separated by a semi-colon). These email addresses don't have to be associated with Commander or Service Portal accounts. They can include group accounts.
When Commander sends an email to a group of people requesting approval for a service request, all people in that group receive the email. As soon as one person has clicked Approve on the approval landing page, other people who have received the same email are no longer able to approve the request. If multiple levels of approval are configured (meaning that multiple Send Approval Email steps were added to the approval workflow), Commander then sends the email to the next person or group in the approver list. If the request is rejected, no other emails are sent.
If a Commander user has Administrator access rights on the relevant cloud account and their email address matches the email address in the approval workflow, the user can also view a list of service requests awaiting their approval and approve requests right in the Commander console.
If a Service Portal user has the required permissions and their email address matches the email address in the approval workflow, the user can also view a list of service requests awaiting their approval and approve requests right in the Service Portal. The required permissions are Approve Requests, Request New Service, and Request Service Change. If the requester is a member of an organization, the approver must be a member of the same organization and must also have the Show All Organization Services permission.
Using variables to populate email addresses
Using variables to populate email addresses allows you to configure dynamic recipient lists. For example, to send the email to the primary contacts of the organization, enter the following variable in the Address List field:
You can pass other variables into the email address field, email subject and email body.
The <a> tag is automatically added to links in emails (only the http protocol is supported). For example, if the value of a custom attribute is a link, the value will be formatted as a link in the email.
If you don't use HTML markup in the email body, the body is assumed to be plain text; <br> and <p> tags are automatically added for new lines.
If you add HTML markup to the email body, however, no additional tags are added.