Insights ServiceNow to Azure DevOps: Working Together in Harmony

ServiceNow to Azure DevOps: Working Together in Harmony

Now more than ever, this is the age of “Digital Transformation”. ServiceNow and Azure DevOps have been rapidly evolving from a systems integration perspective. As of today, there are ServiceNow tasks and pre-deployment conditions supported within Azure DevOps. But, that’s just a one-way direction between the two systems and specifically focuses on updating a ServiceNow record within the CMDB.

What if you need to drive your processes back into Azure DevOps for cloud infrastructure provisioning? If your organization is focused on a DevOps practice based out of Azure, continue reading to learn more about how ServiceNow can get involved!

What are Web Services?

Let’s start here first. Believe it or not, it seems that most software products or platforms offer web services built-in as a core feature today. This is mostly due to users requiring data to be sent into a system (inbound) or data needs to be sent out to an external source of some kind (outbound). Thankfully, there is a capability which exists today that is already included within ServiceNow and allows for this type of functionality. This can be accomplished by utilizing Outbound REST web services within the ServiceNow platform.

Think of the possibilities… with this type of interaction, virtually anything can be achieved! Now, let’s talk about the concept of an endpoint as a specific definition in a dictionary. The system is expecting data in a specific format to perform an operation, and the system processes the request once the data reaches the specific endpoint.

Steps to Configure a REST Message

To begin, a REST Message must be created within ServiceNow to facilitate the communication of outbound requests. Once a name has been given to the REST Message, the following must be configured for messages to send properly:

  1. Create a REST Message record with mandatory REST endpoint (can be dynamic with variables)
    1. By default, ServiceNow creates a GET HTTP method for you and this is a great way to test out the connection to your REST endpoint
  2. Set up Authentication
    1. ServiceNow supports the following types:
      1. Basic authentication**
      2. Mutual (two-way authentication)
      3. OAuth 2.0
  3. Add additional HTTP Methods (POST, PUT, etc.)

**For this scenario, a basic authentication profile consists of a username and password. Azure DevOps requires an authentication token for the password value. For this scenario, I created a token with both read/write Work Item privileges since the intent is to create work items within Azure DevOps.

Notice that I have two HTTP methods set up with this REST message record. The “GET” method is for retrieving data while the “POST” method is meant for creating something new. In this scenario, there’s a requirement for creating a new User Story so we must use the POST method. Note that the “GET” HTTP method can remain within the system with other methods and isn’t required to be used with every REST call – it’s there on standby for any future request to that specific endpoint.

What sets ServiceNow apart from other vendors is the platform allows the user to test a REST message being sent to the endpoint for test runs. This test message will include the test values in the right-most column of the Variable Substitutions, but values can be overridden when calling the REST message to begin with! Simply call the “name” of the variable substitution record you wish you replace the value with and it will plug and play. We will look at this later in the script I’ve put together…


One other item to keep in mind is there are multiple endpoints for all types of resources, especially within the Azure DevOps world. For our scenario, we’re attempting to create a User Story which inherits from the Work Item class. After referring to the Microsoft documentation on how to set up the content body for the request, it appears that it must be formed in Patch JSON.

Each block within the inner section of the JSON represents an Azure DevOps property within the inherited class. In the example above, the title and description of the User Story is being set. For a complete list of fields, refer to this Microsoft article to further extend your Content body.

Quick Tips

  • ServiceNow allows for dynamic values to be passed into the various areas of the REST Message. Simply create a Variable Substitution record and call the name in the line of code with ${} syntax (this syntax tells ServiceNow to reference the substitution as a parameter and can take in any value – test values will be used unless overridden)
  • Azure DevOps classes appear to have a $ in front of the name, so be aware that the $ sign must live within the coded

Scheduled Script

Now that the REST Message is set up and properly configured, we can use it! What we can do is monitor for requests coming from the ServiceNow service catalog and create the respective work item in Azure DevOps. The following script was implemented using ServiceNow’s handy Scheduled Script Execution mechanism within the Scheduled Job suite, on a periodic timer.

The script below uses the RESTMessageV2 API within the ServiceNow platform so that we can call the REST Message when data requirements are met. One item to note is the Basic Authentication line of code requires a string data type for the username and password. The intent here was to never expose the password in plain text, so I retrieved the Basic Authentication Profile with a glide record query and decrypted the value which in turn becomes a string value for the API. See below:


The Outbound web services capabilities within ServiceNow are endless and powerful, allowing the system to be used/extended in a variety of ways. What I explained was only one option for integration purposes, but the approach is customizable for any business need.

See below for a summary of what was built to send out a REST Message:

  • REST Message record with mandatory endpoint
  • Basic Authentication Profile
  • Post HTTP Method
    • Inherited authentication from parent
    • HTTP request
    • Patch JSON data for Content body
    • Variable Substitutions for dynamic values
      • description
      • organization
      • project
      • title
      • type