Utilize Ansible for opening and closing tickets with ServiceNow - Part 1.

Opening and closing tickets is a very common step in network operations. This article will cover the role Ansible can play in ticket automation. I’m going to cover opening a change request in ServiceNow, a popular cloud based SaaS provider. A lot of companies are using ServiceNow as their ticketing system. They provide a developers instance to test your scripts or Ansible playbooks against.

You can sign up for your own free developers instance here: https://developer.servicenow.com

Ansible has a snow_record module that makes it very easy to open and close ServiceNow tickets.


You will need to provide the username, password and instance for authentication to your cloud based ServiceNow instance. Keep in mind the instance should look like this instance: dev99999 not the full url instance:_http://dev99999.service-now.com.


The table parameter will determine what type of ticket will be opened ie.. change_request or incident etc…​

A great way to determine all the parameters available, is to view the JSON dictionary the ServiceNow API sends back after you have created your ticket. I am accomplishing that here by using register to give a variable name to that dictionary and then using debug to view it in the terminal.


This is just a portion of the full dictionary for the sake of brevity. However this is very handy in spelling out the parameters you can add under the data section of your task.

If you want to see just one parameter of the dictionary for example the ticket number. You can simply modify your debug to look like this.


This says in the var new_change_request show me the dictionary named record and the parameter of that dictionary called number.


You could do the same thing with any parameter of the record dictionary (close_code, closed_by, comments, etc…​)

So if you were to log into your developers instance of ServiceNow and view the change>all section. You should see your change request (CHG0030058) at the top.


You should notice that the short description has been filled out by our playbook task. (This is a test opened by Ansible) As well as the priority (2 - High).


After a ticket gets opened we need to of course automate closing or resolving the ticket as well. This can be done by specifying the state parameter in another task. This is where it can get tricky, state is a parameter of the record dictionary as well as a parameter of the snow_record module.


This is a snippet from the record dictionary when we created our ticket, notice the state was -5. The task above will change it to -4


In ServiceNow a ticket needs to be walked through a few different states before it can be closed. The numeric values for the different states can be found in this table from the ServiceNow docs. I recommend you create an Ansible role that will have five tasks each simply changing the state in this order -4, -2, -1, 0, 3 which is a state of Authorize, Scheduled, Implement, Review, Closed. Your organization may have other steps required along the way, hopefully this article was enough to get you started.



Stay tuned for part 2 - Handling incidents in ServiceNow and adding output to your tickets right from your routers and switches.

TheNetwork.Engineer - May 19 2018 - Colin McCarthy

Free DevOps Resources

Get DevOps news, tutorials and resources in your inbox. A perfect way If you want to get started with devops. Like you, we don't like spam.