Embotics® vCommander® provides users with powerful automation to provision and manage virtual and real assets, and save time and money doing so. This is accomplished by using workflows, which provide structure to various aspects of your operations.
There are three types you can configure:
- Approval Workflows
- Completion Workflows
- Command Workflows
To configure approval and completion workflows, access their respective tabs under Configuration > Service Request Configuration. Service workflows are configured under Configuration > Command Workflows.
In the sections below, the choices available to you when creating each type of workflow are examined.
Approval Workflows
Approval workflows allow administrators to either reject or provide consent for requests, and any pre-deployment activity that must occur before provisioning begins. When you create an approval workflow, you make several choices that determine when it is used, and what actions take place.
On the Name & Type page, provide a name for the approval workflow. It’s important to use meaningful names so you will understand at a glance the purpose of the workflow. As you develop your automation over time, and expand the sophistication of your Embotics vCommander ecosystem, this will make management tasks even easier.
Each approval workflow can be applied for new service requests or change requests. Before making this kind of decision, consider the differences in how you want the requests to be fulfilled, and make sure you’re choosing the most suitable option for what you want to accomplish.
The Assignment page is where you configure which users, groups and organizations use the workflow. Each type of workflow (approval, completion and service) may have only a single workflow set as global. Global workflows are used as the default when no other workflows have been assigned to the user, group or organization.
For example, if you have sales and networking teams making requests for production VMs, you would want human decision makers reviewing each request. These are suitable scenarios for a global workflow.
Compare that to automatically approving requests from a quality assurance group who need to regularly set up and tear down lab VMs. It’s unlikely that a human is required for these expected, frequent requests, so creating a unique workflow applied only to the QA group in Active Directory makes sense.
On the Steps page, you add and define steps that are progressed through as part of the approval process. Create steps to Send Approval Emails, Send Email, Execute Approval Scripts, Execute Scripts, or determine Quota Approval.
Approval emails are sent to one or more recipients who can approve the request, permitting automatic or manual deployment of the requested services to proceed. Emails sent using a send email step are used for notification purposes only, and do not allow recipients to approve the request.
Similarly, approval scripts are used to to automatically determine whether a request should be approved so that human intervention is not required, but scripts run from an execute scripts step can perform various tasks, but do not directly impact the approval process. In either case, the scripts can be always executed, or only run when certain conditions are true.
Quota Approval considers user quota, organization quota or both when determining whether or not the request should be approved.
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.
The Automation Options page varies based on whether or not the workflow supports new or change requests.
New requests are optionally automatically deployed without requiring further intervention from an approver or administrator, and may have the primary owner configured as the Windows Administrator. Change requests can be automatically fulfilled whether or not they require a power down of the VM.
With change requests, you configure when to automatically fulfill them, and for which forms.
The Summary page is used to review the configurations you have set before committing them.
Completion Workflows
Completion workflows are used to perform post-deployment activities on VMs, vApps and entire services. When you create a completion workflow, you make several choices that determine when it is used, and what actions take place.
On the Name page, provide a name for the completion workflow. It’s important to use meaningful names so you will understand at a glance the purpose of the workflow. As you develop your automation over time, and expand the sophistication of your Embotics vCommander ecosystem, this will make management tasks even easier.
Each completion workflow can be applied after a service is deployed, after VMs, vApps or unmanaged components are applied, or after change requests are fulfilled. Before making this kind of decision, consider the differences in how you want the requests to be fulfilled, and make sure you’re choosing the most suitable option for what you want to accomplish.
Depending on the choice you make for when the workflow is applied, automation options for each request type become available. You’ll also notice that the name of the third page in the Wizard changes to reflect the choice you make.
On the Steps page, you add and define steps that are progressed through as part of the completion process. Create steps to Send Acknowledgement Emails, Send Email, Execute Scripts, Wait for Event, Perform Power Action or Perform Remove Action. The types of steps available depend on when you have the completion workflow configured to apply. For example, you can’t perform a power action on an unmanaged component, so it will not appear as a choice.
Acknowledgement emails are sent to one or more individuals who must take an action and acknowledge that it has been completed before next steps can be carried out. For example, you could use this step to make sure that an administrator has installed and updated an antivirus program before performing subsequent software installations. Emails sent using a send email step are used for notification purposes only, and do not allow recipients to acknowledge an action has been completed.
Scripts can be executed to perform various tasks or check conditions. In either case, the scripts can be always executed, or only run when certain conditions are true.
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 a script fails, you can allow the workflow to continue if the results are not critically important to the completion workflow.
Wait for event steps check for various conditions before allowing the completion workflow to proceed, helping to ensure that timing-based failures do not occur. You can choose to wait for guest OS customization or power, IP address and/or DNS entries to be obtained, power states and specified amounts of time to elapse. As with the available steps themselves, the options change depending on when you have the workflow configured to apply.
The Assigned Services / Assigned Component / Assigned Forms is used to specify whether the workflow is used globally by default, or restricted to specified services, components or forms, depending on when the workflow is applied.
The Summary page is used to review the configurations you have set before committing them.
Command Workflows
Command Workflows are independent of approval and completion workflows, and used to automate command sequences for Embotics vCommander or service portal users. Service workflows can be run on demand, scheduled by users, or run in response to a policy being triggered.
On the Name page, provide a name for the service workflow. As with the other workflow types, it’s important to use meaningful names so you and your users will understand its purpose at a glance. The icon displayed in the service portal catalog is also selected on this page. You can use one of the default options, or upload your own.
On the Steps page, you add and define steps that are progressed through to enact the service requested. Create steps to Send Approval Emails, Send Email, Execute Approval Script, Execute Script, Wait for Event, Perform Power Action or Perform Remove Action.
Approval emails are sent to one or more recipients who can approve the request, permitting automatic or manual deployment of the requested services to proceed. Emails sent using a send email step are used for notification purposes only, and do not allow recipients to approve the request.
Similarly, approval scripts are used to to automatically determine whether a request should be approved so that human intervention is not required, but scripts run from an execute scripts step can perform various tasks, but do not directly impact the approval process. In either case, the scripts can be always executed, or only run when certain conditions are true.
Wait for event steps check for various conditions before allowing the completion workflow to proceed, helping to ensure that timing-based failures do not occur. You can choose to wait for guest OS customization or power, IP address and/or DNS entries to be obtained, power states and specified amounts of time to elapse. As with the available steps themselves, the options change depending on when you have the workflow configured to apply.
Perform power action steps are provided so that you can be sure that you are working with a VM in a specified power state. You can choose to always execute the step or to only execute the power action when certain conditions are met. The available power actions are start VM, stop VM, shutdown guest & stop VM, reset VM, shutdown guest OS, and reset Guest OS.
Lastly, perform remove action steps allow you to automate deleting VMs from disk and/or removing VMs from inventory. As with other steps, you can choose to always execute this type of step, or confirm a condition exists before proceeding.
The Permissions page is where you define which users and groups have access to the service workflow.
On the Options page, configure whether or not a confirmation dialog appears to users requesting the service, and whether or not the workflow appears as a command for permitted users on the service portal command bar.
The Summary page is used to review the configurations you have set before committing them.