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.
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.
Assign Approval Workflows
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, you should also 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's an established order in which approval workflows are applied.
Order of precedence in which approval workflows are applied
- Approval workflow assigned directly to the user.
- Approval workflow assigned to an organization of which the user is a member. If the user is a member of multiple organizations, the organization will be the one the user was signed in to when making the request.
- 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.
- Global approval workflow is used.
Add 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 recipients who can approve the request, permitting automatic or manual deployment of the requested services to proceed.
- Send Quota Approval Email — Sends approval emails only after considering user quota, organization quota, or both when determining whether or not the request should be approved.
- Send Email — Sends emails for notification purposes only; they don't allow recipients to approve the request.
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.
- For details on the steps that you can add to workflows, see Workflow Steps Reference. 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\. For more information, see Use Plug-In Workflow Steps. - 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 Resource Changes That Require Reboots.
Require user authentication to access approval email links
To secure who can approve or reject service requests with approval email links, you can set the embotics.workflow.approval.link.auth.enabled system property to true. This system property is set globally for a Commander instance. The property defaults to true on new Commander installations, and false on Commander upgrades. For more information on setting system properties, see Advanced Configuration With System Properties.
With this system property enabled, Admin Portal and Service Portal users accessing approval email links will be required to authenticate their account before being redirected to the approval landing page. Only those with valid user accounts and sufficient roles and permissions will be able to approve or reject service requests.
For an Admin Portal user to approve a service request:
- An email address associated with your account must be included in the Address field in the approval workflow step.
- You must have one of the following access rights for the cloud account: Administrator, Operator with Approval, or Operator. For more information, see Assign Access Rights to Administrative Users.
For a Service Portal user to approve a service request:
- The email address for the user or the user’s group must be included in the Address field in the approval workflow step.
- The user must belong to the same organization the request originated from.
- The user must be assigned a Service Portal role with the Approve Requests permission. For more information on Service Portal roles and permissions, see Customize Service Portal Roles for Users.