VMware vRealize Automation – Approval Policy options in vRealize Automation

When doing vRealize projects, I noticed that the approval policies are an appealing concept to customers. However they do not always fully fit the requirements of the customer especially when looking at the provisioning process of virtual machines.  User interactions can be alternative to offer extra flexibility. This blog post will first explain the basic concepts of approval policies and user interactions followed by the reason whether to use approval policies or user interactions.

Approval policies: general explanation

Approval policies are an out-of-the-box feature of vRealize Automation (vRA, formerly known as vCAC). It allows the business to create processes and policies for all kinds of reasons. For example when a user of the vRA portal requests a machine with more than 2 CPU’s, an administrator, notified via mail and via the inbox tab in the vRA portal, can approve the request or deny a request. The approval can be triggered before the machine is created (pre-approval) or after machine is created (post-approval).

Screen Shot 2015-03-02 at 19.43.48


In the example mentioned above., the approval policy is triggered based on the amount of CPU’s  requested for the virtual machine. However there are numerous other conditions on which it can be triggered and more are being added with every vRA release.

Approval policies also have the flexibility to configure accept/deny permissions for users/administrators in various setups. The permissions can be assigned to individual users or to a group of users. The two main setup options you can choose are:

  • Anyone can approve: anyone in the given group of user can accept or deny. The first decision is the one that counts.
  • All must approve: everyone in the given group of users (even when entering a, active directory group) must accept/deny the approval.

An approval policy can consist of different steps of approvals ,resulting in an infinite number of different policies and approval processes.

The brief explanation given shows the flexibility approval policies offer.

There is one downside of the approval policies: the default behavior of rejecting an approval is to delete the request or dispose the virtual machine. This can be a huge disadvantage for some use cases. Post approval policies can be used as a mechanism to notify an administrator that a machine has been provisioned and could be a trigger to start an additional post-provisioning external process before the user is allowed to use his newly provisioned virtual machine. A machine provisioned with an approval policy will not be handed over to the user (read: not shown in his items in the portal) until the approval is accepted so this fits the requirement perfectly.

Approval policies can be used to notify an administrator to start an external business process

The use case described above is not really the purpose of approval policies but can be used by the business this way.  One issue with using approval processes for this purpose is the fact that the default behavior of denying an approval is to dispose the virtual machine. If the approval is a trigger for an external process, chances are low to have the need to dispose the machine since it is an extension of the provisioning process. However chances are real that an administrator (accidently or because the external process takes longer than expected) clicks on reject, resulting in a lost and disposed virtual machine. Not really an appealing thought for the user who requested it.


Disposing the virtual machine in case of an approval rejection is desired in most use cases. If an approval is rejected, the machine is not allowed to exist in the first place according to the approval administrator.

User Interactions: general explanation

A user interaction is an element that can be used in vRealize Orchestration (vRO, formerly known as vCO). It will halt the workflow in which it is used and it will query the user for extra information or will give a user extra information concerning a task that needs to be performed (hence the name user interaction). A user interaction can be fully customized with needed variables and actions based on user requirements but do not offer out-of-the-box flexibility concerning user permissions that the approval policies do (but workarounds are possible).

Example of a user interaction in a simple vRA stub workflow

An extra benefit of user interactions is that it perfectly works together with the vRA portal. When using a user interaction in a stub workflow for machine provisioning, it will prompt the user for input by creating a message in the inbox. A stub workflow is a vRO workflow that is used to manipulate certain phases of the virtual machine life cycle process. The most frequently used phases are:

  • Building
  • Provisioned
  • Disposing
  • Expired

What if…

… we use user interactions instead of approval policies? That would be pretty cool right? We could:

  • control the behavior of the user interaction using workflows
  • change the flow of our stub based in the input of the user
  • not have the chance of disposing a virtual machine by accident

Yes, but…

… there is a catch. The ‘machineprovisioned’ stubs triggered from vRA have a workflow time-out. By default this is 30 minutes (this value can be changed). In practice this means that if you create a user interaction in a stub workflow, the user will have 30 minutes to respond to that user interaction. The provisioning of the virtual machine will fail if the time-out expires. Increasing the time-out period is an option but it is not a real solution since it will just delay the problem.

Invoking a user interaction workflow in an asynchronous way solves the workflow timeout. However it will not prevent the virtual machine to be available for the user until the user interaction has been approved. Reason for this is that the main flow of the stub will continue and will eventually end. The asynchronous called workflow containing the user interaction on the other hand will halt until confirmation is given. This will eventually result in a finished stub, a provisioned virtual machine and a waiting user interaction.

timeline user interactions

User interactions can offer extra flexibility compared to regular approval policies. If you can live with the vRA workflow timeout constraint, they can be a great alternative in some use cases. If not, it is recommended to stick with the built-in approval policy mechanisms.

Update 6 may 2015: In case it was not pointed out clearly in this post, I do not recommend using user interactions instead of approval policies due to various limitations. It should also be noted that user interactions can only send an inbox entry to the requestor of the workflow by default.