Request and manage vRealize Automation catalog items from ServiceNow

“We have ServiceNow and want to use its service management portal instead of vRA, is this possible?”  This question comes up a lot from our customers and often with a follow up questions “Can we wrap ServiceNow approval policies around it?” The answer is YES!

There are 2 ways to achieve this, the first is using VMware’s vRealize Automation plugin for ITSM which is available here.  The main premise of this plugin to expose the exact vRA services and catalog items directly within ServiceNow. This is good and all, but it does not provide a lot of flexibility and the application installation and configuration is complex.  Check out these blogs for additional information on v7.6.1 and v5.0.

The second solution, and what I will be using is SovLab’s ServiceNow connector module, which is very easy to implement and provides a lot of flexible by allowing ServiceNow administrators to customize the catalog and the request process directly within the ServiceNow platform.  It has the following highlighted features:

  • Multi-tenant & vRA instance support
  • Platform-native control for ServiceNow which means management and and customization is done directly within ServiceNow and also using ServiceNow constructs (catalog, workflow, etc.)
  • Day2 vRA operations support
  • Request as ServiceNow user automatically maps to corresponding vRA user, so also no requirement for SAML or ADFS!
  • SovLabs Template Engine support for metadata injection and custom logic, which is a huge plus
  • Can be coupled with the SovLabs CMDB Module, which is very useful and something everyone needs.

So lets start with the implementation prerequisites:

As a prerequisite you need a ServiceNow instance and a MID Server installed and configured. I assume this is already done so I will not provide steps here for this.

Some other SovLabs related prerequisites you need to take care of:

  • a ServiceNow instance with a MID Server installed and configured.
    • I assume this is already done so I will not provide steps here for this.
  • ServiceNow connector plugin software
    • SovLabs license key
  • For the ServiceNow tables: “question_choice”, “sc_cat_item” and “item_option_new” you have to set All Application Access for Can read, Can create, Can update, and Can delete
    • Go to System Definition > Tables > question_choice
    • Go to Application Access
    • For All application scopes, make sure Can read, Can create, Can update, and Can delete are checked
    • Repeat Step 2 and Step 3 for the other tables
  • The ServiceNow usernames needs to match their vRA username
    • Unless SovLabs ‘User Mapping’ is used, which you can read about here
    • I just setup the usernames in ServiceNow to match my domain username login for vRA.  “”
  • If you want to perform Day2 actions you have to install and configure the SovLabs ServiceNow CMDB module as well. Check out my blog on this.
  • Administrator credentials to vRO that also has entitlements to the Business Group/Catalog Items being Imported to ServiceNow

Installation and configuration steps:

  1. Login to ServiceNow
  2. Go to System Update Sets -> Retrieve Update sets
  3. Select Import Update Set from XML
  4. Choose the ServiceNow Connector xml file.
    1. You can request a 45 day trial from SovLabs here
    2. Click upload
  5. SovLabs Connector should now be available, select it.
  6. Click Preview Update Set
  7. Click Commit Update Set
    1. If successful then the connector is installed
  8. In the left side navigation bar type SovLabs in search
    1. Select Installation Wizard
  9. Click Begin Installation
    1. Verify that all checks are green.
    2. If you run into issue review the documentation here
  10. Select SovLabs -> Licenses
    1. Click New
    2. Paste the license received from SovLabs.
    3. Click Submit
  11. Select vRO Server
    1. Enter the vRO server name
    2. Enter vRO hostname
    3. Select port 443 if embedded vRO
    4. username
    5. password
    6. Select Mid server to use
    7. Select vRA tenant name
    8. vRA service account is optional
      1. If not entered then the default vRA Host connection of the tenant is used.
    9. Click Submit
      1. You will get an error if the connection is not successful
    10. Note: Multiple vRO server can be created for connection to separate vRA environments.
  12. Now lets import a Catalog item
    1. In navigation bar select SovLabs -> Import vRA Catalog Item
    2. wordpress-0006
    3. Enter the ServiceNow Catalog Item name
    4. Enter the description
    5. Select the default number of deployments
    6. Select the ServiceNow Catalog where the catalog item will reside
      1. This is optional and can be assigned later
    7. Select the ServiceNow workflow
      1. By default you will select “SovLabs – Request vRA Catalog Item”
      2. This however can be a custom workflow create by the ServiceNow admins. (The custom workflow just needs to have the SovLabs – Request vRA Catalog Item added as a subflow)
    8. Select the vRO server
    9. Select the vRA Business group
      1. Check the box “Business Group Override” if you want to have the ability to select the Business group in the Catalog item request form.
    10. Select the vRA catalog item
      1. wordpress-0008.jpg
    11. Click Load Request Form
      1. This will list all Custom Properties associated to the catalog item and the VM object.
      2. wordpress-0009.jpg
      3. Select the custom property you want to map to the ServiceNow catalog item.
        1. a ServiceNow Label and Name will automatically be created, but you can change this.
        2. These mappings will create variables in the Service Catalog item as Single line text type, which means all properties definitions within vRA of different data types (boolean, string-dropdown,string,date-time, etc would need to be recreated)
    12. Click Import Catalog Item
    13. wordpress-0010.jpg
    14. From the Catalog Item page you will see all your variables that was mapped, and you also have the ability to test run a deployment by clicking the  “Try It” button on top left hand side.
    15. Next step as mentioned your ServiceNow administrator needs to update the variables to either duplicate what you have in vRA or use ServiceNow logic to lookup information from CMDB tables.  The admins have a lot of creative flexibility to configure the catalog items to your own business standards.

Managing Catalog items:

Managing your existing catalog items are also very simple, for instance what if you added new custom properties in vRA to an existing blueprint that has been imported into ServiceNow?

  1. First off, create a variable for the new custom property in the ServiceNow Catalog Item
    1. In the ServiceNow navigation search bar type “Catalog”
    2. Select Catalog -> Maintain Items
    3. Select your ServiceNow Catalog itemwordpress-0012.jpg
    4. Scroll down and under the Variables tab, click the New button.
    5. wordpress-0011.jpg
    6. At a minimum, Enter the Question (Text that will be displayed in the request from) and the name of the variable (that will be mapped to vRA catalog item)
    7. Click submit
    8. wordpress-0013.jpg
  2. In the navigation bar, select SovLabs -> Modify Catalog Item Mapping
    1. wordpress-0014
    2. a New browser tab will open
  3. From the drop-down select the catalog item you want to modify
  4. Wait for all the information to load
  5. wordpress-0015.jpg
  6. You can check the box for the newly added custom property and from the Servicenow Item field drop-down, select the new variable that was just created.
  7. wordpress-0016.jpg
  8. This will complete the new mapping of the custom property and make it available in the request form.


An example of my blueprint in vRA for a two tier application deployment.


  • As you can see I use a single vSphere machine for each tier with the OS based on image component profile selection.
  • With SovLabs Property toolkit and other modules I have no blueprint sprawl.


The two tier blueprint/catalog item from ServiceNow deployment perspective.



  • Allow for multi-tier deploy option, which are all separate imported catalog items.
  • We also allow for custom environment deployments which has a broad range of questions asked to the user for those one of manual deployment.



  • There are 3 distinct areas
    • Request properties
      • Top level blueprint properties which affects both tiers.
    • Application Server – Properties
      • Specific configuration settings for the application tier VM
      • We also allow for multiple app server deployments
    • Web Server – Properties
      • Specific configuration settings for the web tier VM
      • We also allow for multiple app server deployments
  • Having ServiceNow as your management catalog provides a lot more flexibility because additional logic can now be build into ServiceNow which feeds custom properties to vRA, which in turn again manipulated there with SovLabs Property Toolkit module
    • For instance, the custom deployment checkbox might only be made available to specific users like VMware admins in ServiceNow request form.
    • When the custom deployment is selected it opens additional field selections to select a custom IPAM profile and domain.
    • wordpress-0026.jpg
    • Values can be pre-populated for instance Business unit can have a lookup on users profile
    • Application list can be pulled from a table


General recommendations:

  • If you plan on using SovLab’s ServiceNow vRA Connector as your front-end request form:
    • Get buy-in from your ServiceNow team. This modules provides the opportunity to build your service catalog and request form based on existing company practices, which means a ServiceNow administrator might be needed to build out the request form and more complex logic.
    • In vRA do not create any property definitions with specific types or logic and just leave everything as an empty string.
      • Custom property definitions from vRA are imported as string into the ServiceNow Catalog item variables.  You do not want to manage it on both sides.
      • Also, if the values don’t match between ServiceNow and vRA your deployments from ServiceNow will fail, which adds additional overhead to keep it in sync.
      • External Script actions will not work and that lookup logic needs to be build into ServiceNow
  • Create a ServiceNow table for all the lookup values associated with Catalog Item variables.
    • Specific users can be provided permission to this table to update existing records or create new ones.
    • The table can be shared between different catalog items for lookup.
    • wordpress-0027.jpg
  • Setup an alarm/alert to monitor the status of the mid server.  To many times has this been the culprit for deployments failing.
  • Setup a development and testing environment
    • GPC_ServiceNow&vRA.png
    • Development ServiceNow
      • Create 2 vRO servers for both your development and Production vRA
      • Import the same catalog item from both prod and dev vRA
    • Production ServiceNow
      • Create vRO server for production vRA environment
      • Import the catalog item from production vRA
    • Change process: (this might sound complicate the first time)
      1. Make changes and perform tests on the dev ServiceNow instance and imported dev vRA catalog item
      2. When all changes have been verified, make the same changes on the prod vRA catalog item, as well as the imported prod catalog item on dev ServiceNow.
      3. ServiceNow team can now create an update set of the production catalog item on dev ServiceNow instance, and during the maintenance window the update set can be pushed to the Production ServiceNow instance.
        1. In some cases customers will have a test ServiceNow instance as well where the changes are push to first before going to prod.
      4. Repeat

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s