Creating Approval and Pre-Provisioning Workflows

Approval workflows are triggered when users make service requests. Approval workflows allow you to handle pre-deployment activity for new service requests as well as pre-fulfillment activity for change requests. Some example tasks covered by an approval workflow include:

In this topic:

Who gets approval "rights" when an email is sent?

When Commander sends an email to a group of people requesting approval for a service request, all people in that group receive the email.

However, only one person in the group can approve or reject the request. As soon as one person in the group approves the request, the request is moved to an Approved state, unless additional approval steps are configured. If the request is rejected, no other emails are sent.

Approval workflow assignments

You can create only one global approval workflow for new service requests and one global approval workflow for change requests. If you don't want the global workflow to apply to all organizations, users and groups, you can override the global workflow if you create additional approval workflows and assign them to specific organizations, users, and groups.

Likewise, you can assign only one new service request approval workflow and one change request approval workflow to a particular organization, user or group.

If multiple approval workflows are assigned to a user, approval workflows are applied in the following order:

User logs into the Service Portal as an organization member

User logs into the Service Portal as "self" (that is, not as an organization member)

  1. Approval workflow assigned directly to the user
  2. Approval workflow assigned to an organization of which the user is a member (if the user is a member of multiple organizations, the organization is the one the user was logged into when making the request)
  3. Approval workflow assigned to an AD group of which this user is a member. If there are multiple AD groups, the approval workflow assigned to the nearest group is applied. If the AD groups are at the same level, the approval workflow assigned to the lowest group (alphabetically) is applied.
  4. Global approval workflow
  1. Approval workflow assigned directly to the user
  2. Approval workflow assigned to an AD group of which this user is a member. If there are multiple AD groups, the approval workflow assigned to the nearest group is applied. If the AD groups are at the same level, the approval workflow assigned to the lowest group (alphabetically) is applied.
  3. Global approval workflow

Creating approval workflows for new service requests

Access through:

Configuration menu > Self-Service > Approval tab

Available to:

Commander Role of Superuser and Enterprise Admin

To create an approval workflow for new service requests:

  1. Click Add.

    As a shortcut, you can select a workflow in the list and click Copy. This option can save you time because it copies much of the workflow's existing configuration.

  2. On the Name & Type page, provide a name for the workflow, and from the Apply this workflow menu, select When a new request is created. Then click Next.
  3. On the Assignment page, assign the workflow to an organization, to users and groups, or both. Then click Next.
  4. On the Steps page, click Add and select a step to include in the workflow module, and then set its configuration parameters in the Step Details pane.

    When configuring steps, you should consider the following points:

    • By default, steps execute automatically. However, you can set steps to execute only for specific conditions. To make a step conditional, select Step Execution > Execute when conditions are met, then click Edit and define the condition. See Making Workflow Steps Conditional for more details.
    • You can click vars-20x20 in any text field that supports variables to open the Variable Assistant. The Variable Assistant allows you to select variables for the current context and access help for each variable.
    • By default, if a step fails when a workflow is run, no re-attempt to execute it is made. If you want a workflow to re-attempt to execute a step if it fails, select the step, then click Add > Retry Selected Step. For more information, see Adding Retry Steps to Workflows.

    For details on built-in steps, see Workflow Steps Reference. 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.

  5. Continue to add steps to the workflow module, as appropriate. Click Next when done.

    To change the order of a step, use the up and down arrows, or click Delete to remove it.

  6. Click Next after you've finished adding steps.
  7. On the Automation Options page, specify whether approved requests will be automatically deployed.
    • To allow administrators to manually deploy requests, select Manually deploy approved requests.
    • To deploy VMs and virtual services automatically once the service request has received approval, select Automatically deploy approved requests.

      Notes:

      • To enable automated deployment, you must also configure a deployment destination on the target managed system. See Configuring Automated Deployment for Approved Service Requests.
      • vCenter only: If you selected Automatically deploy approved requests and you want the primary owner to be set as the administrator of the VM during the automated deployment process, enable Set primary owner as administrator.
        If you select this option, any Windows VM that is configured with a customization specification in this workflow will automatically assign the primary owner to the local Administrator group.

      Important: The VM customization process may proceed for some time after the VM is created. If anyone logs into the VM and interrupts the customization process, the primary owner won't be added as administrator. To ensure that the service requester isn't prematurely notified that the VM is ready for use, add a Wait For Event step to your completion workflow. From the Wait For menu, choose Guest OS customization to complete, and in the Wait Time field, enter 1800 seconds.

  8. On the Summary page, enter a comment about the workflow in the Description of Changes field, review your settings and click Finish.

    For the description of changes, you can indicate the purpose of a new workflow or, if you are editing an existing workflow, indicate what changes were made.

Creating approval workflows for change requests

Access through:

Configuration menu > Self-Service > Approval tab

Available to:

Commander Role of Superuser and Enterprise Admin

To create an approval workflow for service change requests:

  1. Click Add.

    As a shortcut, you can also select an existing workflow in the list and click Copy.

  2. On the Name & Type page, enter a name for the workflow, and from the Apply this workflow menu, select When a change request is created. Then click Next.
  3. On the Assignment page, assign the workflow to an organization, to users and groups, or both.
  4. On the Steps page, click Add and select a step to include in the workflow module, and then set its configuration parameters in the Step Details pane.

    When configuring steps, you should consider the following points:

    • By default, steps execute automatically. However, you can set steps to execute only for specific conditions. To make a step conditional, select Step Execution > Execute when conditions are met, then click Edit and define the condition. See Making Workflow Steps Conditional for more details.
    • You can click vars-20x20 in any text field that supports variables to open the Variable Assistant. The Variable Assistant allows you to select variables for the current context and access help for each variable.
    • By default, if a step fails when a workflow is run, no re-attempt to execute it is made. If you want a workflow to re-attempt to execute a step if it fails, select the step, then click Add > Retry Selected Step. For more information, see Adding Retry Steps to Workflows.

    For details on built-in steps, see Workflow Steps Reference. 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.

  5. Continue to add steps to the workflow module, as appropriate. Click Next when you're done.

    To change the order of a step, use the up and down arrows, or click Delete to remove it.

  6. On the Automation Options page, specify whether approved requests will be automatically fulfilled.
    • Choose the default fulfillment behavior by selecting from the Default Fulfillment Behavior drop-down menu.

      Optionally enable the Immediately fulfill changes not requiring power down checkbox, if you want any part of the change request that doesn't require powering down the VM to be fulfilled immediately upon approval.

  7. To set a different behavior for a specific form:
    • Click the form's checkbox and select a fulfillment behavior from the menu.

      Optionally enable Immediately fulfill changes not requiring power down for the change request.

    The fulfillment behavior options are:

    • Manual: An administrator must fulfill change requests manually. If you enable Immediately fulfill changes not requiring power down, any part of the change request that doesn't require powering down the VM will be fulfilled immediately upon approval.
    • Automatic/Scheduled: The request will be fulfilled during the next maintenance window. If you enable Immediately fulfill changes not requiring power down, any part of the change request that doesn't require powering down the VM will be fulfilled immediately upon approval. See Hot/cold resource changes for each cloud platform below to learn which tasks require a power-down.
    • Automatic/Immediate: All changes, including those requiring a power-down, will be fulfilled automatically upon approval. If you select this option, you can't deselect the Immediately fulfill changes not requiring power down checkbox.
  8. On the Summary page, enter a comment about the workflow in the Description of Changes field, review your settings and click Finish.

    For the description of changes, you can indicate the purpose of a new workflow or, if you are editing an existing workflow, indicate what changes were made.

Deleting approval workflows

Access through:

Configuration menu > Self-Service > Approval tab

Available to:

Commander Role of Superuser and Enterprise Admin

At any time, you can remove a workflow from Commander. After you've removed a workflow, all settings associated with the workflow, including approvers and actors, emails, scripts and any deployment information, are no longer available. To use those settings again, you must associate them with another workflow.

To delete an approval workflow:

  1. Select a listed workflow.
  2. Click Delete and confirm the deletion.

Hot/cold resource changes for each cloud platform

The following table indicates whether a VM must be powered down for various resource reconfiguration tasks.

Not Supported indicates that this type of resource change is supported by the cloud platform, but not supported by Commander.

 

Power down required?

vCenter

SCVMM

AWS

Azure

GCP

Modify CPU / memory resources OR change instance type

Dictated by CPU Hot Plug and Memory Hot Plug settings for the VM in vCenter

Yes

Yes

Yes

Yes

Add network adapters

No

Yes

Not Supported

Not Supported

Not Supported

Delete network adapters

Yes

Yes

Not Supported

Not Supported

Not Supported

Modify network adapters

No

No

Not Supported

Change subnet: Yes

Other changes: Not Supported

Not Supported

Add storage

No

No

No

No

Not Supported

Delete storage

No

No

No (base disk can't be deleted)

No (base disk can't be deleted)

Not Supported

Modify existing storage

No

Yes

Not Supported

Yes

Not Supported