ServiceNow with Zomnio

Zomnio is our easy to use cloud IVR and Call Center platform. This will be a closer look at some of the more advanced features of the Zomnio platform, focusing on ServiceNow integration.

Follow along with this guide, or feel free to create your own ServiceNow IVR using our pre-built template. Sign up today and select ServiceNow when creating a new voice application. Trial accounts are completely free, no credit card required!

Here’s a high-level view of the features we’re going to create:

  • Queue up an available agent.
  • Automatic ticket creation in ServiceNow (pre-populated with the answering agent’s data)
  • Screen Pop to the agent with newly created ticket

The example we’re going to walk through today makes a few assumptions:

  1. You have ServiceNow setup for your organization.
  2. Your agents in Zomnio and ServiceNow were registered using the same email addresses.

Setting Up Your Application

Let’s start with some quick setup to make creating your call flow easier.

Set Data Step

The Set Data step lets us define some variables to use later in call flow. Click the settings button (“…” right next to the trash can icon) to input your custom variables.

Here you can input the URL to your ServiceNow instance so you don’t have to keep typing it throughout the call flow.

Next, let’s put together the basic flow each call will take:

  1. First we’ll have a greeting/instructional prompt.
  2. We create a ServiceNow incident.
  3. We then transfer them to a queue to be connected to an Agent.
  4. We update the incident with the answering Agent’s details.
  5. We screenpop on the Agent’s desktop with the ticket details.

Creating an incident

Here we’ve started building out our call flow with the options for connecting to an agent. When the caller selects to be transfered to an agent we use the ServiceNow step to create a new incident. Notice we use the {service_now_url} we created earlier in the Set Data step in the URL field. It’s also very important to name the step (here we called it servnow) so that we can reference its data later in the call. Lets look at the settings.

We set the Action to CREATE, and the Target Table to INCIDENT which will create a new incident when running this step. You can also input other fields in the ServiceNow Body to add more details to your new incident. In this step, and all others that require integration with ServiceNow, don’t forget to input your credentials (username and password). Next we go to the Screen Pop step. This step defines all the actions that happen after an agent answers the call. The settings here a little more complicated. Lets take a look:

Connecting to an Agent

Here we set the SCREEN POP URL to: {service_now_url}nav_to.do?uri=incident.do?sys_id={!servnow.result.sys_id}. Lets break that down into pieces and make sense of what’s going on:

We again use the service_now_url as the base URL and include the endpoint to take us to a particular incident detail view( nav_to.do?uri=incident.do? ). Last we’re passing in data returned from the previous ServiceNow step. Every ServiceNow or REST step returns JSON data that we can use later in the call flow.  {!servnow   lets us reference the previous step using it’s name, and .result.sys_id will give us the newly created sys_id of that incident (found in the JSON response).

The next portion is the Screen Pop Actions. These are REST steps that are executed when an agent answers. Here’s what we’re doing with the two actions shown here:

  1. We’re making a GET request to ServiceNow to get the sys_id of the agent that answered the call.
  2. We’re making a PUT request to the ServiceNow incident we created earlier and assigning this agent to that incident.

Lets look at the settings for those two Screen Pop Actions. First the GET request:

The URL is: {service_now_url}api/now/table/sys_user?sysparm_query=email=[!agent.email]

We again start with  service_now_url  (see why using Set Data can be a lifesaver!?) and add the API endpoint in ServiceNow for the Users table:  api/now/table/sys_user?. sysparm_query=email= tells ServiceNow to search for an agent by email address. The last part: [!agent.email] is how we tell Zomnio to use the agent email of the answering agent. This dynamic data is only available to the IVR after an agent answers so we reference it with brackets [ ] instead of the usual braces { }.

Lastly, let’s look at the PUT request.

The URL is: {service_now_url}api/now/table/incident/{!servnow.result.sys_id}.

This should look familiar by now. We start with the service_now_url and add the ServiceNow API endpoint for the incident table: api/now/table/incident/. The last part {!servnow.result.sys_id} is the same code we used earlier to access the sys_id of the incident we created at the start of the call.

The HTTP Body has the actual data we are updating on the incident. In this case {"assigned_to": "{screenpop.actions[0].result[0].sys_id}"}. We are updating the assigned_to attribute on the incident. For the data, let’s break down that very long code:

{screenpop.actions. screenpop is the name of the Screen Pop step.
.actions contains the results from all of our Screen Pop Actions in an Array. So screenpop.actions[0] will have the results of the first Action. The screen pop step lists the index on the left side of the Screen Pop Action list for reference.
.result[0].sys_id is referencing the result of the GET request we made earlier. Here we are retrieving the sys_id from that request (which in this case is the answering agent’s user sys_id in the ServiceNow database).

The PUT request tells ServiceNow to update that incident with the data we supplied.

Wrapping Up

That was a lot of information. Luckily, you can get started today with this template already filled and waiting for your ServiceNow information. As always, if you need something more custom or have any questions reach out to us using the Contact button at the top.