Slack + ServiceNow for Developers

#Integration , #Allan Leinwand , #Slack , #Kingston

Dave Slusher

4 minute read

SlackSN.png

frontiers.jpg

Last week at Slack Frontiers, a big announcement was made about a new partnership between Slack and ServiceNow. Allan Leinwand (our CTO) joined April Underwood of Slack to discuss and demonstrate the upcoming prebuilt integration between the two services to be released in Kingston. The video is here and the ServiceNow announcement begins around 14:30. Allan also has a blog post discussing the partnership.

If you watch the video and/or read the announcement, you might be wondering exactly what this means for ServiceNow developers. It sounds cool but what is different before and after the Kingston release that makes this news?

The Slack integration as demonstrated in that video will be one of the initial starting integrations provided by a new capability in Kingston. You can currently integrate with Slack today. They provide a REST APIB and ServiceNow provides REST message capability. However, what will make this different is the ease with which it can occur. To integrate currently requires you to

  • build a REST Message V2 configuration
  • figure out where you want to call it from - Workflow, Script Include, triggered from a Business Rule, etc
  • determine the format of the payload to send
  • figure out exactly what you want the outbound message to look like and where to pull the information from
  • testing the whole stack from beginning to end

This is not at all impossible. For many of us, it’s what we do. There are many episodes of Live Coding Happy Hour where we do exactly this process for a number of external APIs. Where this makes it different is in the execution. If you watch the Slack video, that’s an accurate representation of the process. The steps I listed above contain somewhere between an hour or two of work at best, and a day or two at worst. In order to replicate this process in Kingston, the timescales range from seconds to minutes.

This works in a manner that will be intuitive to most developers. If you’ve ever used IFTTT or Zapier it is a familiar paradigm. There is a trigger in the system. As of Kingston, these are mostly record state changes such as “Record Created/Updated” or timed triggers such as “Hourly” or “Daily”. Given a trigger, you can then specify an action or series of actions that should be carried out. “Send a message to Slack” is one of these actions, and via drag and drop it can be added to the flow. The only required data is to add the Slack webhook URL that you can configure for any channel that you are logged into. There are optional configurations like setting the user that will be sending the message, the channel and icon but none of those are necessary and all can be configured on either the Slack or ServiceNow side.

When assembling the messages to get sent, you can use the same data “Data Pill Picker” control that currently exists in the Automated Testing Framework (aka “the cannonball” aka “the martini glass”.) If you configure the trigger to be a change or creation of an Incident record for example, then down in the action you are able to use that UI control to pick fields of that same record as parameters to the action. This can be for the message itself, where you probably want to include the record number and/or the short description in most cases but it is not limited to it. For example, the same control can be used to control the username sending the Slack message such that it can be coming from the user who made the most recent update. The sky is the limit on using the data from the triggering record.

Using this new capability will have familiar concepts for anyone who has set up a Workflow. On editing, you’ll have the option to “Activate” in order to make it effective for newly created flow, analogous to “Publish” for Workflows. The main difference between the two is that Workflows are defined with a series of low-level activities to take place. Flows tend to be defined by high level features to exercise such as “Post to Slack” or “Add to VTB”. There are certainly intersections in capabilities such as the “Ask for Approval” action and similar. The main difference will be in the “fiddliness” of setting them up. This will be faster as it is driven less by the specific details and more by the outcomes.

Developers will have a lot of interesting things to explore in the Kingston release. Getting familiar with these new capabilities will be at the top of most people’s list. It will make integrating Slack into your ServiceNow workflow a simple task that can be accomplished quickly with minimal fuss on the details so you can spend your time digging into better problems. Look forward for this in the Personal Developer Instances once Kingston is released for Early Access this fall!