Updating ServiceNow with Hardware Asset Data using Logic Apps

This is part 4 of the scenario Perform Automation Based on Device Enrollment in Microsoft Intune.

This article describes how to modify the previous step so that instead of sending an email, we create or update an asset record in ServiceNow.

Figure 1 – From Logic App to ServiceNow

Figure 1 is a simple representation, but there are actually several steps behind the scenes to make this work. Figure 2 provides a more in-depth description of the remaining work to complete this scenario.

Figure 2 – Update CMDB Logical Flow

As you can see from Figure 2, we have to perform some extra queries to understand which actions are appropriate. Also, the asset model is a required field when creating an asset, so we need to either query to get an existing model ID, or if no matching model is found, we must create a new Model. Once we know we have a model, we then create an asset and link it to the model.

The process of creating an asset also creates a CMDB record by default, with limited information. So in all cases, we will update the CMDB record with additional information.

Depending on your company’s expertise in Logic Apps vs. ServiceNow, you could perform all of these steps in ServiceNow as well. For this article, we will build it all in Logic Apps. Figure 3 shows the query to ServiceNow, and if the device already exists, update CMDB.

Figure 3 – If the serial number already exists, update the CMDB record.

Before building out the remainder of this flow, ensure you have a ServiceNow developer instance with a configured service account. Figure 7 in that article shows the service account and the delegated rights. Since this article will create models and assets, you must also add the roles named asset and model_manager, as shown in Figure.4

Figure 4 – Granting rights for model and asset management.

Building out the rest of the flow

Start by cloning your current DeviceEnrollment Logic App so that you have a backup, and then in your DeviceEnrollment Logic App, remove the send email step we created in the previous article.

List Records with Matching SerialNumber

First, we must query ServiceNow to see if this device already exists in the hardware asset table, and then we build a condition to take us down the right path for subsequent steps.

  1. Add a new action, choose ServiceNow, and then List Records.
  2. If this is the first time connecting to ServiceNow, you will be prompted to connect. Enter the service account and password that we created in How to: Obtain a ServiceNow Developer Instance and Configure API Integration.
  3. For Record Type, choose Hardware.
  4. For Query, note that you will be using the query language from ServiceNow. For this step, you will enter serial_number= and then insert the dynamic variable for SerialNumber, as shown in Figure 5.
  5. Verify the information in Figure 5.
Figure 5 – The ServiceNow List Records action
  1. Add a new action called Condition.
  2. For the Condition, we must count the number of records returned from the previous step in Figure 5. Click on the condition filter field, and click on Expression in the pop-up. Enter the following expression:

length(body(‘List_Records_with_matching_SerialNumber’)?[‘result’])

  1. If, by chance, you named the previous step for listing records from ServiceNow differently, be sure to update that expression.
  2. Verify the information as shown in Figure 6 and then select Update.
Figure 6 – Creating a Custom Expression
  1. After selecting Update, you should see the conditional step with a branch for true and false, as shown in Figure 7.
Figure 7 – Conditional branch based on whether the serial number already exists in the ServiceNow asset table.

Update Existing Record in CMDB

We have confirmed we have an asset, and for this article, we’re going to assume that all asset information is set correctly (I’ll follow up with another article that will give other considerations depending on your environment).

As mentioned previously, the Asset and CMDB records are paired together in ServiceNow-they are different records with their own attributes. However, by default, there are business rules in place so that when you touch one, you may impact the other.

Since we have machine fact information from Intune, let’s use that information to keep the CMDB accurate.

What is a machine fact? Machine fact is gold! It is data that humans haven’t touched, and haven’t had an opportunity to touch or make dirty. For example, when you query the win32_operatingsystem WMI class, you receive operating system details from the Windows system that are detected by the operating system (things like memory, operating system version, last bootup time, and more). These machine facts are your best source of information for use in reporting, asset management, and configuration management.

  1. Add a new action, choose ServiceNow, and then Update Record.
  2. Choose Record Type of Computer (this ties to the appropriate CMDB class).
  3. For System ID, choose the dynamic variable Configuration Item, which was obtained from the List Records with matching SerialNumber step.
  4. Since this data is coming from Intune, you can set the Discovery source as Intune (note that Intune is not a default option in ServiceNow – work with your ServiceNow team to add this option or choose an available value, such as Other Automated).
  5. Set other desired variables, as shown in Figure 8. For my example, I’m mapping the AzureADdeviceID to the CMDB attribute Object ID, as this will help with future scenarios for correlation, uniqueness, etc. I also use the Intune property lastSyncDateTime for the CMDB attribute Most recent discovery, which helps understand the activity of a device and can help with asset management. Also, as shown in Figure 8, you can see that Logic Apps automatically identified this as a potential array (although for the way we built this, you will always have an array of size one by the time you get to this point).
Figure 8 – The process to update an existing record in CMDB.

Creating a New Asset in ServiceNow

And now, to follow the conditional check for an existing record down the false branch. This process is a little more involved, as shown previously in Figure 2.

When creating a new asset in ServiceNow, you must specify a model for that asset. The Model table is a relational table to the asset, so if the model does not yet exist, you need to create the model first, or asset creation will fail. Figure 9 shows an overview of creating a new asset. First, we check if the model exists, and if not, create the model followed by the asset, and then update CMDB (you can think of them as dependencies for now – Model->Asset->CMDB configuration item).

Figure 9 – The process to create a new asset in ServiceNow (as well as update CMDB).

As we have walked through these steps a few times, the next few items will be abbreviated and show you the highlights of each action, without walking you through the details.

First, we must check if a model exists. We do this by querying the ServiceNow Hardware Model class. Notice this time I set Display System References to Yes. This will give me a human-friendly model name that I can use to compare against the model I received from Intune, instead of a model identifier that’s unique to ServiceNow. So build your query as shown in Figure 10 to query for name=<your dynamic variable for model>. And similar to our conditional for checking for an existing device by serial number, create a new conditional here with the following expression:

length(body(‘List_Records_-_see_if_Model_exists’)?[‘result’])

If, by chance, you named the previous step for listing models from ServiceNow differently, be sure to update that expression. Figure 10 shows the query and the conditional.

Figure 10 – The query and conditional to check if a model exists.

If the model exists, we follow the true branch and create an asset, followed by updating the (newly-created) CMDB configuration item, as shown in Figure 11. Notice the Create Asset action below uses the Create Record ServiceNow action, and the Update CMDB action uses the Update Record ServiceNow action. Notice for Model we pass the Sys ID, which is a unique identifier in ServiceNow for the model obtained from our model query step.

Figure 11 – Creating a new asset and updating CMDB for an existing model.

If our conditional check for model returns that the model does not exist, we must create the model first. Figure 12 shows the high-level steps and classes involved in creating the model. We then take the Sys ID from the Create Model Record step and use it when creating the asset record. Finally, we update the CMDB record for the newly-created asset (details are not shown below but are the same as the last step in Figure 11).

Figure 12 – Creating a new model, asset and updating CMDB.

Congrats! You now have an example Logic App for processing information from Intune and inserting it into ServiceNow! As mentioned, this is one way to achieve this task. ServiceNow provides multiple ways to integrate via API, but this is a great starting point with using Logic Apps.

If you missed it, check out the initial article for this scenario to see all the steps from beginning to end. I also posted sample templates in GitHub.

Happy Automating!

Greg

P.S. A big Thank You! to Donnie Taylor for helping me troubleshoot some of the pain around Logic Apps and the ‘standard’ alert coming out of Log Analytics – hopefully Logic Apps will build some magic to easily consume that payload in the future.

P.P.S. Also a big Thank You! to Greg Nottage for running through my draft article and providing feedback for how to make it more usable.

How to: Obtain a ServiceNow Developer Instance and Configure API Integration

ServiceNow Developer instances are great to help you learn more about ServiceNow, test functionality, or just try to break it. These SaaS instances power up very quickly, and you have the ability to wipe them and start over anytime you’d like. I want to show you how easy it is to obtain a developer instance of ServiceNow and start kicking the tires. And since most of my articles will focus on automation, we’ll include the (basic) configuration for API integration to SerivceNow.

For anyone in the ServiceNow community, this article will be a no-brainer. For many of my blog followers, this will be new territory and is essential for following along in some of my upcoming articles.

Create an account to obtain a developer instance

  1. Navigate to https://developer.servicenow.com/ and select Create an Account.
  2. Walkthrough the ServiceNow registration steps
  3. Once you have registered, log in to https://developer.servicenow.com/ and select Request an Instance.
  4. ServiceNow release versions are named after cities, in alphabetical order. So as you can see in Figure 1, you can choose from Madrid, New York, and Orlando. Orlando is the latest release. Choose the latest release available to you and select Request.
Figure 1 – Requesting a ServiceNow Instance
  1. Normally when you choose the latest release and select Request, your instance will be available in a matter of seconds!!! You’ll receive a notification as shown in Figure 2.
Figure 2 – Instance Ready Notification
  1. Take note of your instance URL and admin password, and then select Open Instance to launch the ServiceNow instance. (Also note that the instance is reclaimed after 10 days of inactivity).
  2. On the first login, you’ll be prompted to change your password. Take care of that, and then you will see the ServiceNow home page, as shown in Figure 3. *Note this is the administrator view.
Figure 3 – ServiceNow Home Page, Madrid Release (Administrator View)
  1. Congrats! You have a developer instance of ServiceNow!

Create a Service Account for API Access

Now that we have an instance, we need to create a new user to be used as the service account for API access. For this example, we will enable basic access and authentication. For a production deployment, work with your ServiceNow team for a more secure method (such as OAuth).

  1. In the left-hand navigation, type ‘users’ and then navigate to System Security->Users and Groups->Users, as shown in Figure 4.
Figure 4 – The Users table
  1. As you can see in Figure 4, the developer instance includes sample data. Click New to create a new user. Populate the user information, similar to Figure 5, enter a password and select Submit.
Figure 5 – Create a Service Account
  1. Next, select that record to open it back to the detail view, select the Roles tab and click Edit as shown in Figure 5.
Figure 6 – Edit User Roles
  1. From the Edit Members page, grant the following roles: itil, and snc_platform_rest_api_access as shown in Figure 7. This will give your service account enough rights to Create/modify incidents, requests, and perform other ITIL functions. Be sure to restrict service account access as much as possible for your production scenario.
Figure 7 – Adding Roles to the Service Account
  1. Click to Save changes.

Test API Access using PowerShell

Read Test

Now it’s time to test! You could use Postman or any API testing tool, but we’ll use PowerShell here. Use this sample code:

$cred = Get-Credential
$results = Invoke-WebRequest -Uri "https://dev80150.service-now.com/api/now/table/alm_asset?sysparm_limit=1" -Method Get -Credential $cred
($results.content | ConvertFrom-Json).Result

When run, this code will prompt for credentials (enter the credentials you created with the service account), and then query your ServiceNow Developer instance and return one result (sysparm_limit=1).

Write Test

Now let’s do a quick write test to ensure it’s working as desired. This example will create a (very) basic incident:

$cred = Get-Credential
$body = @"
{
    "short_description":"Loud Fan on notebook"
}
"@

$results = Invoke-WebRequest -Uri "https://dev80150.service-now.com/api/now/table/incident" -Method Post -Credential $cred -body $body  -Headers @{'Content-Type' = 'application/json; charset=utf-8'}

($results.content | ConvertFrom-Json).Result

You can also see the created incident number in the returned result.

  1. From ServiceNow, type Incident in the top-left search bar, as shown in Figure 8.
  2. Next select Open under Incident.
  3. Click on the gear icon to select/re-order columns.
  4. Your newly-created incident should appear at the top of the list (if not, click on Number to re-sort.
Figure 8 – Finding your newly-created incident

This is a basic example of creating an incident that is only here for you to verify connectivity. I have found that many applications advertise they integrate with ServiceNow, and while true, the integration they support could only be used in a lab environment. Most business processes will require more information than the minimum required fields for ServiceNow. The challenge is that every company/business process requires different fields and data for things such as an incident. My recommendation to anyone who wants to integrate with ServiceNow is to also have an advanced option, where I (as an automation admin) can provide a JSON of the fields that I want to pass from the 3rd party application to ServiceNow. This is not a one size fits all world.

Congrats! You now have a ServiceNow instance that you can successfully query and create items! Stay tuned for how we will leverage this instance in future articles. Take advantage of the REST API Explorer and start to do some amazing things.

Greg