Making Workflow Steps Conditional

You can specify that workflow steps are executed only when specified conditions are met. Setting conditions can help you:

make a workflow more flexible - for example, you might want to install an antivirus program only on Windows VMs.

add an extra level of approval to a workflow - for example, require a two-stage approval if the user requests resource changes.

You can make an entire workflow conditional by adding only a single conditional step to it. For example, you can create an approval workflow that will trigger the approval process only if the monthly cost of the request is greater than a specified amount. If the amount is lower than what you specify, the approval workflow will run, but no approval emails will be sent, and the request will move to the Approved state.

To set a condition, use a combination of variables, operators and constants (numbers, Booleans or strings). Note that the workflow type determines what variables you can use. More on variables

For another example that includes a conditional workflow step, see the Knowledge Base article Installing Software Using Completion Workflows.

Available operators

Table: Available Operators

Operator

Description

-eq

equals

-ne

not equals

-gt

greater than

-ge

greater than or equals

-lt

lesser than

-le

lesser than or equals

-contains

contains

-notcontains

not contains

-and

Boolean operator; combines two conditions and requires both of them to be true

-or

Boolean operator; combines two conditions and requires at least one of them to be true

-not

Boolean operator; negates a condition

Example:

"#{target.guestOS}" -contains Microsoft

Example: Conditional approval workflow

To create a workflow that triggers the approval process only if the monthly cost is greater than $100:

1.Go to Configuration > Service Request Configuration > Approval Workflow.

2.Create an approval workflow for new service requests or change requests.

3.On the Assigned Groups page, decide whether to apply this workflow globally or to specific users or groups.

4.On the Steps page:

Add a Send Approval Email step to the workflow.

In the Step Execution drop-down menu, select Execute when conditions are met.

Click Edit next to the Step Execution drop-down menu.

In the Variable Assistant, enter the following in the Condition field:

"#{request.cost.monthly}" -gt 100

Variable Assistant

In the Address List field, enter one or more email addresses (semicolon-separated).

Customize the Email Body as required.

5.Complete the rest of the wizard. More on approval workflows

Example: Making a workflow step conditional on a previous step

To make a workflow step conditional on whether a previous step has run, use the variable #{steps[x].skipped}, where x is a step number (beginning at 1) or name. This variable returns True if the workflow step did not run, and is supported in all workflow types.

For example, you might want to allow Service Portal users to back up their VMs using a script you've developed, but this requires the VM to be powered off before it runs. You also want to make sure that if the user requested the backup while the VM was powered on, the VM is powered on again after the backup.

Step 1: A Perform Power Action step, with the action Start, with a condition to run only if the VM is powered off. The condition would read:

"#{target.state}" -ne "Not running"

It's important to handle this step this way, instead of making the execution conditional on the state Running, because VM can have several states (including Saved, Starting, Stopping, Suspended and more).

Step 2: Some other action

Step 3: A Perform Power Action step, with the action Start, with a condition to run only if Step 1 did not run. The condition would read:

"#{steps[1].skipped}" -eq true

Example: A single workflow covering multiple service types

vCommander supports multiple service types, including:

VM

Virtual Service (including vApps and cloud services)

Database

Load Balancer

Auto Scaling Group

Stack

You can use the "#{target.type}" variable to run a workflow step only on a particular service type. This variable allows you to support multiple service types in a single workflow.

For example, to specify that a step will be carried out only on load balancers, enter the following in the Condition field of the Variable Assistant:

"#{target.type}" -eq "Load Balancer"

The #{target.type} variable is supported in the following workflow types:

Approval workflows for change requests

Component-level completion workflows

Command workflows

More example step conditions

The following examples apply to approval workflows for change requests and to completion workflows.

Specify that a step will be carried out only if the requested number of CPUs is greater than two:

"#{target.settings.cpuCount}" -gt 2
 

Specify that a step will be carried out only on Windows VMs:

"#{target.guestOS}" -contains Microsoft
 

Specify that a step will be carried out only if resource settings (CPU, memory or storage) have been modified on the request form:

"#{request.resourcesChanged}" -eq true

More complex examples using Boolean operators

Conditional Send Approval Email step

We want to use a Send Approval Email to notify the admin to create an Active Directory computer account before the workflow continues, but only if the previous Execute Approval Script step completed successfully, and the requested service is a Windows VM. In this example, the Execute Approval Script step is the second step in the workflow. Note that because the service description may contain spaces, the entire variable is surrounded by double quotes. We make the Send Approval Email step conditional, using the following condition:

("#{steps[2].exitCode}" -eq 0) -and ("#{request.services[1].components[1].description}" -contains Windows)

Conditional Perform Power Action step

We want to power off certain running VMs. In each of the following examples, we're adding a Perform Power Action step with the action Stop, and making the step conditional.

Power off running AWS VMs:

("#{target.state}" -eq running) -and ("#{target.managedSystem.type}" -eq amazon_aws)

Power off running VMs, unless they're Azure VMs:

("#{target.state}" -eq running) -and (-not ("#{target.managedSystem.type}" -eq ms_azure))

Power off running AWS and VMware VMs:

("#{target.state}" -eq running) -and ("#{target.managedSystem.type}" -eq amazon_aws) -or ("#{target.managedSystem.type}" -eq vc)

Troubleshooting

When you encounter a syntax error, check for the following first, and then review the next section for more information:

mismatched and misplaced parentheses

an operator without a hyphen preceding it

unclosed quotes

Syntax rules

Invalid conditions are evaluated to false.

You must enclose each variable in quotation marks.

When using Boolean operators, you must enclose each condition in parentheses. For example:

("#{target.state}" -eq running) -and ("#{target.managedSystem.type}" -eq amazon_aws)

Parameters with spaces must be enclosed in double quotation marks. For example:

"2012/03/12 08:30"

Because conditions are parsed after variable substitution has occurred, if a variable value will contain spaces, the entire variable must be enclosed in double quotation marks. For example:

"#{request.requestedServices[1].components[1].description}"

No escaping of characters is supported; escape characters are passed as is.

An empty string "" is used to indicate null or not set.

If a variable can be resolved as a number, a Boolean entity, or a date, it will be treated as such; otherwise it will be interpreted as a string.

Number: A positive and negative floating point number or integer

Boolean: True or false, case-insensitive

Date: YYYY/MM/DD hh:mm:ss

A variable will be resolved as a date if it matches one of these patterns:

YYYY/MM/DD hh:mm:ss

YYYY/MM/DD hh:mm

YYYY/MM/DD hh:

YYYY/MM/DD

where:

YYYY = four-digit year

MM = two-digit month (01=January, etc.)

DD = two-digit day of month (01 through 31)

hh = two digits of hour (00 through 23) (am/pm NOT allowed)

mm = two digits of minute (00 through 59)

ss = two digits of second (00 through 59)

Accuracy of date matching is determined by the specified date.

Example 1: "#{target.settings.expiryDate}" -gt 2012/01/11 would resolve to true for VMs with an expiry date after Jan 1st 2012 at 00:00:00

Example 2: "#{target.settings.expiryDate}" -lt "2012/03/12 08:30" would resolve to true for VMs with an expiry date before March 12 2012 at 08:30:00

Example 3: "#{target.settings.expiryDate}" -gt "2012/04/01 13:" would resolve to April 1st, 2012 at 1:00:00 PM or later

For strings and enumerations:

All string comparisons are case-insensitive.

If the data type of a vCommander variable is an enumeration, then the list of string choices is limited.

If the left and right side of the expression are not the same data type, the expression will evaluate to false. For example:

"#{target.cpuCount}" -eq true

The data type for the left side of the expression is Integer, and the data type for the right side is Boolean, so this expression will evaluate to false.

If the left side of an expression cannot immediately be interpreted by vCommander and the right side of the expression is a date, the left side will also be evaluated as a date. For example:

"#{any.numeric.property}" -eq 2010/01/01

This expression would be evaluated as two dates.