Slack is a real time messaging platform that makes work entertaining with many ways to integrate third party tools to create powerful and interesting interactions. ServiceNow is a PaaS & SaaS provider for internal service management, automation, & orchestration. Together, they have offer a wide range of opportunities. Today, we will be integrating the two.
ServiceNow boasts a wide range of APIs that can be used to integrate external applications with your instance. Each API is very useful, but they all have their own limitations. So, before you head down the path of a processor, please consider these other APIs to determine whether any of them can fit your needs. It will save you time & resources.
Processors can have many many uses. They are an extremely powerful tool that can be used to solve a myriad of problems. However, when you have a hammer, everything looks like a nail. Today, we will use it to integrate slash commands with Slack.
Just to get this out of the way: “Why should I use a Processor over the Scripted REST API?”
Answer: Maybe, you shouldn’t. The scripted REST API is a wonderful way to consume external REST calls, but it does have limitations. The Slack slash commands have a content type of “application/x-www-form-urlencoded” while Scripted REST resources only support “application/json”, “application/xml”, and ”text/xml” currently. So, processors are the way to go.
Processors allow developers to create a custom URL endpoint where we can run server-side scripts and return anything we want. This functionality will allow your instance to consume REST calls in any way we desire. This allows us to build better integrations with 3rd party applications.
Here is some documentation on the stuff I’ll be touching upon in this tutorial:
So as long as you can complete this tutorial by Joey Day, You should be all set. In fact, I use stuff built in his tutorial at the end of this tutorial. I WOULD HIGHLY RECOMMEND YOU COMPLETE HIS TUTORIAL FIRST.
The result of this tutorial will be an integration that allows you, the developer, to create slash commands in Slack that create records in a custom table in ServiceNow which you can then respond to with simple Business Rules.
Here are a few things you will need to build this:
- A slack channel — if you don’t have one, you can create one here
- A slack developer account — You can create one here
- A ServiceNow instance — you can get developer instance if you create an account here
Step 1. Create the Processor
Go to System Definition > Processors. Click New.
Set an appropriate name for the processor. I called mine Slack Processor. Set the Type to script. Write a description & add a Path. The path will determine the endpoint URL for Slack to POST our slash commands to.
Then add this code into the script function:
This code will help us by logging all of the incoming data from Slack which will later help us build the staging table for the application. Write down the Path you created. The URL that you will give slack to post to will be like this:
For example: MyCompany.service-now/myPath.do
if you want you can add a parameter. This will make the URL this instead:
parameter = “hello”
For example: MyCompany.service-now/myPath.do?hello
If you add a paremeter, you are able to pass in values into using the URL. Do not share this URL. Now, click Submit.
For more information on processors
Step 2. Make the processor public
The processor will currently require credentials to be accessed, but Slack doesn’t have credentials. So, we will have to make it a public page. Type in sys_public.list into the search bar on the left and hit enter. It will bring you to a list of all the public pages for your instance. Click New
Enter just your Path into Page section. Do not add your entire URL. Click Submit
Step 3. The Slash Command
Go back to your Slack App window. We are now going to get Slack talking to ServiceNow. Click Slash Commands under Features
You may have to enable Slash Commands. This is just authorizing your application to list for slash commands in your slack channel. Click Create New Command.
For now, make your command /test and put the URL you created from the end of Step 3 into the Request URL field. I would also check the Escape channels, users, and links sent to your app box
Now, click Save.
Step 4. First Test
Go to your slack Channel and enter this command /test data and hit enter. Slack will now send a post to your processor’s URL endpoint, but it won’t show anything happening on the Slack side. There will be logs of all the headers, and parameters as well as the method type in ServiceNow.
Go to System Logs > System Log > All and search “slack” to find your logs.
We now have Slack talking to ServiceNow! Congratulations!
Step 5. Build the Staging Table
Using the logs from our previous test, we are now going to build our staging table.
Create a new table by going to System Definition > Tables and clicking New. Give it a name like Slash Commands. I also autonumbered mine and created a menu for it. We will later get into the cleaning up the table & menu and adding security.
Now from my logs, I am going to create dictionary entries for the following:
- response URL
I used String or URL as a field type where appropriate. Name the Column Label the exact same as the parameter name. ServiceNow will append “u_” to the front of it in the Column Name field. It will also replace dashes (“-”) with underscores (“_”). We will have to address this in our processor script when we start to populate the table.
Step 6. Replacing the Processor Script
Replace all of the code in your processor’s script with this code:
Now, all of this code could be put into a script include & I would actually suggest you do that. For now, I won’t.
Step 7. Test the slash command again
Go back to your channel & run your slash command. Then go back to the list view of the table you created in step 6. You should see a new record. Open up the record & make sure all of the data is populated. You may have misspelled something the first time, just delete the dictionary entry and add a new one with the correct spelling. Rerun your slash command if this happens to confirm it works correctly
Congratulations! you now have a table which contains all of the information from the REST call.
Step 8. Responding/Running Server side actions
From this point, you can do anything with this data. Create, update, delete, send emails, start workflows, etc. However, I suspect that you will be likely to want to respond to the command with a slack message from ServiceNow. That is where Joey Day’s tutorial comes in handy.
Create a new business rule for your slack table. Make it an advanced business rule & SET THE When FIELD TO AFTER, NOT BEFORE. You will get all sorts of weirdness if you run a business rule before insert on a REST call and its a pain to diagnose if you aren’t familiar with it. I would also add a filtered condition that searches for a matching command
I combined/modified two of Joey’s scripts and added a bit of my own code to create this script which will allow us to respond:
If you were clever, you could create a new script include specifically for slash commands based off of Joey’s script include. Here would be a great place to start with that.
Now, rerun the slash command in your instance. If everything was done correctly, you should receive a response! Congratulations!
Highly Recommended: Adding Some Security
When we created the processor & made it public, we made it available for anyone with the URL, and I mean anyone, to access it. So, we will add a bit of security to this now. As we discovered before, when a slack app sends a slash command post to an endpoint it sends many pieces of data. One of them is the Token. The Token is a code that validates that the command was from your Slack application. This is a very important piece of information and should be kept secret.
I am not going to pretend that I am an expert in IT security. However, I do have a few suggestions based on Slack’s documentation, experience, & common sense.
- Validate the REST Call using the token field
Your command’s “token” field is a unique token from your application validating that it is from Slack. So, I would reject it with a 403 status & log the contents for later viewing or have another table for forbidden access like a black hole of data to analyze later.
2. Reject all REST methods except POST
For this project, I consider all POSTs to be creating a record of a request.
3. Validate user_id & team_id
I would highly suggest storing user_id & team_ids as a field in user table & group table respectively. This makes responses & security easier. You could use these user_ids to identify what users are able or allowed to do.
4. Turn off web services for your staging table. There is sensitive information in there like your token.
5. Add ACLs to make sensitive fields only viewable by admin
6. Add Edge encryption for sensitive fields.
I truly believe that all data centers have some vulnerability. Its best to limit the possible damage & spread of any infiltration by encrypting any sensitive data
7. Create records from any slash command, but only run on validated slash commands
8. Add ACLs to remove the ability for users to create new records
9. Make all fields populated by the REST call read only
10. Replace your code with Script Includes.
Slack is a really cool tool and building an integration with it & ServiceNow opens the doors to many possibilities. This was a really fun project for me and I really hope you find it helpful & useful. If you really liked this tutorial: share it & follow me on twitter, Jeff Manville. I will probably post more tutorials on integrating Slack & ServiceNow as well as other integrations.
Thanks for reading!
I am also offering a more advanced integration between Slack & ServiceNow which includes developer & training documentation, added security, several script includes to reduce complexity, and a better data architecture. Help a young college engineering grad continue to live at the beach. Email me at email@example.com with the subject “Slack Integration” if interested.