Creating Approval Workflows

Approval workflows allow administrators to either reject or provide consent for user service requests, they also allow administrators to efficiently carry out any pre-deployment activity that must occur before provisioning approved services. Approval workflows can be applied for new service requests or change requests.

Assigning Approval Workflows

When you create an approval workflow, you must decide when to use the workflow and who can use it. You must also decide what actions the workflow will take — these actions are defined in a series of workflow steps.

You can set which specific users, groups, and organizations use the approval workflow. When no other workflows have been assigned to the user, group, or organization, global workflows are used as the default . You can create only one global approval workflow for new service requests and one global approval workflow for change requests. However, if you don't want to use the global workflow for all organizations, users and groups, you should create additional approval workflows and assign them to specific organizations, users, and groups.

Note that you can only specifically assign one new service request approval workflow and one change request approval workflow to a particular organization, user, or group. However, if a user inadvertently is assigned multiple approval workflows (for example, because of organization membership or being part of an AD group) there is an established order in which approval workflows are applied.

Order of precedence in which approval workflows are applied to users

  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 signed in to 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

Adding workflow steps

When you configure an approval workflow, you can add steps that are progressed through as part of the approval process. Common approval workflow steps may include steps to send emails and execute scripts:

Send email steps:

  • Send Approval Email — sends emails to one or more recipients who can approve the request, permitting automatic or manual deployment of the requested services to proceed.
  • Send Quota Approval Email — first considers user quota, organization quota, or both when determining whether or not the request should be approved before sending approval emails.
  • Send Email — sends emails for notification purposes only; they don't allow recipients to approve the request.
  • Note: When Commander sends an approval email to a group of people, everyone in that group receive the email. However, only one person can approve or reject the service request. As soon as a person 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.

Execute script steps:

  • Execute Approval Script — automatically approves requests so that human intervention isn't required — you can set the script to automatically approve the request or make it conditional on whether certain conditions are met.
  • Execute Script or Execute Embedded Script — performs various tasks, depending on the scripts that you provide for the step, but they don't directly impact the approval process. In either case, the scripts can be set to always execute, or you can make them conditional and only execute when certain conditions are met.
  • Scripts can be configured to timeout after a defined number of seconds, and the output can be optionally captured as part of the service request’s comment log. Capturing output as comments allows you pass usable information back for processing, to handle activities such as setting a VM name. When an approval script fails, the service request cannot proceed, but with other scripts, you can allow the workflow to continue if the results are not critically important to the service deployment.

Notes:  

  • See Workflow Steps Reference for details on the steps that you can add to workflows. For details on supplemental plug-in workflow 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 for more information.
  • Some requests for resource changes may involve an automatic reboot during change request fulfillment. For information on whether a reboot will be performed for resource changes, see When Resource Changes Require Reboots.

Creating approval workflows for new service requests

Access through:

Configuration > Self-Service

Available to:

Commander Role of Superuser and Enterprise Admin

To create an approval workflow for new service requests:

  1. Click the Approval tab.
  2. Click Add.

    Tip: You can also select an existing workflow and click Copy. This option can save you time because it copies the selected workflow's configuration.

  3. 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.
  4. On the Assignment page, assign the workflow to an organization, to users and groups, or both. Then click Next.
  5. 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.

    Notes:

    • By default, steps execute automatically. However, you can set steps to execute only for specific conditions. To make a step conditional, from the Step Execution drop-down list, select Execute when conditions are met. Then click Edit and define the condition. See Making Workflow Steps Conditional for more details.
    • 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.

  6. Optional: By default, if a step fails when a workflow is run, no re-attempt is made. If you want the workflow to re-attempt to execute a step if it fails, select an added step from the Step Order section, then click Add > Retry Selected Step. For more information, see Adding Retry Steps to Workflows.
  7. 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.

  8. Click Next after you've finished adding steps.
  9. 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 cloud account. 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's 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.

  10. 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 > Self-Service

Available to:

Commander Role of Superuser and Enterprise Admin

To create an approval workflow for service change requests:

  1. Click the Approval tab.
  2. Click Add.

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

  3. 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.
  4. On the Assignment page, assign the workflow to an organization, to users and groups, or both.
  5. 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.

    Notes:

    • By default, steps execute automatically. However, you can set steps to execute only for specific conditions. To make a step conditional, from the Step Execution drop-down list, select Execute when conditions are met. Then click Edit and define the condition. See Making Workflow Steps Conditional for more details.
    • 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.

  6. Optional: By default, if a step fails when a workflow is run, no re-attempt is made. If you want the workflow to re-attempt to execute a step if it fails, select an added step from the Step Order section, then click Add > Retry Selected Step. For more information, see Adding Retry Steps to Workflows.
  7. 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.

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

  9. 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 a power-down is fulfilled immediately upon approval. For more information about which tasks require a power-down, see When Resource Changes Require Reboots.
    • 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.
  10. 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 > Self-Service

Available to:

Commander Role of Superuser and Enterprise Admin

At any time, you can delete a workflow. After you delete a workflow, all settings associated with the workflow are no longer available, such as approvers and actors, emails, scripts, and any deployment information. To use those settings again, you must associate them with another workflow.

To delete an approval workflow:

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