Open Site Navigation

Sending Blocks with the Slack Spoke

Updated: Dec 10, 2021



I've been meaning to write more on Now Experience Workspaces and Components but as I find myself weaving in and out of various parts of the ServiceNow ecosystem as part of my role as a developer my attention has been diverted to my latest endeavor: Using the Slack Spoke in IntegrationHub. Honestly, I've never used IntegrationHub before, and have dealt minimally with Flows. There are some great Fladvocates out there who know way more about this realm than I do, but as the nature of the job and the maturity of the instances I work with lean more into this space, the more knowledgable I'll become.


While the Slack Spoke is easier to set up than other spokes I'm sure, there were some interesting things I came across while setting this up that I'd like to call out. This is by no means an exhaustive article on the functionality of this spoke, I won't even get into Interactivity and creating Incidents, etc. from Slack to ServiceNow. What I'll mostly be covering is the basic set up of the spoke, and how to send blocks to make your outgoing messages look pretty. I want to give a shout out to Chris Helming from the SNDevs Slack for giving me inspiration and answering my questions. Chris knows tons of Slack knowledge and really inspired me to take this from basic text to actually making it look nice.


Slack Bot


So you'll need to either be the Slack Workspace Admin or find one to assist you on this part. The product documentation does a good job of walking through the basics, though if this your first time setting up a bot in Slack there may be parts of the setup you don't need just quite yet and really isn't pointed out in the documentation.


The Workspace Admin will need to create a new app through the Slack API, and this is where you'll set all the permissions and get the tokens for your bot. There's an option to create the app from scratch or from a manifest. If you don't have another Slack app you can pull the manifest from you can just create it from scratch and you'll connect it to the workspace you want to use it in from here.



Since I'm just exploring this I just named my bot Outage, but it can be used for a variety of purposes and could be named very vaguely. The next step concerning Client ID, etc. is pretty self explanatory, you'll use these values in ServiceNow later. On the OAuth & Permissions page, the product documentation just gives a laundry list of everything they think you'll need for their various plugins and out-of-the-box functionality, but this really depends on what you'll be doing. If the Workspace admin is ok with granting all of these it will be easier to expand into further functionality, but you may not need all of them.


I mentioned that the product documentation goes through setting up things you may not need right away, like Slash Commands and Interactivity. For example, I'm just sending things to Slack for this article, so I don't need users interacting with it via Slash Commands or Shortcuts. I mention this because because it really depends on your use case for the spoke and if you're new to Slack development you may not know what these steps are for, I know I didn't until digging deeper into my app. I do also want to note that the product documentation gives super basic information for these sections that will not get you very far without further configuration and reading of the Slack API material. One important thing to know is that the Request URL for Interactivity provided is actually a Scripted Rest API installed with the Slack spoke.


https://<instance-name>.service-now.com/ api/sn_slack_ah_v2/slack/<slack-app-name>/interactivepayload

The last step on connecting a bot was done automatically for me when I added the Bot Token scopes in the OAuth & Permissions section but here's the article in case. You can also give your bot an icon and a name and this can be changed if you'd like in the future (just remember to update anything configured on the ServiceNow side to the new name).



ServiceNow Connection


Before getting to the fun stuff we have to set up the connection in ServiceNow. There's a Connections tab in Flow Designer that acts as a shortcut to do this but you could do it the hard way with Connection & Credential Alias module as well.



This is pretty straightforward and doesn't have really any gotchas unlike the Twitter connection (where you have to name the Credential the same as your app). Just follow everything in the Add Slack connection in ServiceNow Instance and Provide Signing Key in ServiceNow instance sections and it'll set you up enough to send things to Slack. If you want to go further with Interactivity and Inbound Decisions the directions are there as well, but it all depends on how you're using the spoke.


Note: Since I was the Workspace admin for this when clicking Configure and Get OAuth Token I was able to allow it in a different window. I don't know how this looks for non Workspace admins, but I'll post an update when I implement this in an enterprise Slack. If you know, please drop a comment below.


Flow


I created a new Flow in Flow Designer, and I did notice if you create the flow in the Slack Scope you do have access to tables such as Outage. This really depends on your app, scopes, etc. but I figured it would be better to package this as part of the Slack Scope rather than Global. I also set it to run on each unique change since I want to trigger my message when an outage is inserted, details are update, and the outage has ended, but this is subjective to what your flow needs to do. There's also the option to dig deeper into Changed Fields in your Flow Logic later to really get granular on when these should trigger and what type of message you want to post (or not) depending on what's changed.



Since there are three types of outages in ServiceNow by default, and each with their own colors and icons (I used different colors from OOTB) I wanted to mimic this when sending messages so users that were used to looking at the Service Portal could quickly glance at a message in Slack and know which type of outage it was. I then linked the outage to the corresponding page in the Service Portal so the user could quickly jump to it if they wanted to.


Since I'm keeping it simple for this post I created some Flow Logic based off the Type field of the Outage and will post different Slack messages for each one. You'll see there is a Slack and Slack WebHooks spoke, and my guess is one is free and one isn't and the non-free one has more out-of-the-box stuff than the free one. I went with the Slack spoke that requires IntegrationHub for this, as this is what my organization will be using, To note the icon on the Slack WebHooks is the older icon so I'm going on the assumption this is what used to be offered and hence why it's in most of the videos out there before the IntegrationHub Slack Spoke came out, not to mention it's free so if people are trying to make videos off their PDIs they will probably only have access to this one. I call this out because when I started this journey I had no idea of when I would want to use one versus the other, so I hope this clarifies.



I'm using the Post Message action, and I set up the following:



The Channel ID is actually an alphanumerical ID you get by right clicking on the channel you want to the message to, selecting Channel Details, and at the very bottom in super tiny print the ID is there, copy and paste this in. Note: Also make sure your bot is in the channel, you can do this by @mentioning your bot in the channel you'd like to add it to and there should be a prompt in Slack to add it, if your bot isn't in your channel you'll get an OAuth error from your flow.


I'll set up the Blocks in a moment, but want to mention the Username can be whatever you want and it looks like you can use script here to be dynamic, and you can use a different icon here rather than your bot icon and script for dynamic icons here too. I got a pro-tip from Chris Helming that emojis can be transparent so I uploaded a custom emoji to my workspace and I am calling it here.


You can either send Messages or Blocks. Messages are basically plain text but you can format them to use Markdown for links, bold, etc. Blocks allow for rich message formatting and allow us to make things look pretty. There is a lot of documentation for the Block Kit on Slack's site. There is even a great drag and drop Block Kit Builder f(thanks again, Chris) that you can use to prototype your payload for your low and there's some templates on there as well.


It is important to note that you cannot simply copy and paste your Block Kit Builder payload into the Block script in Flow Designer. Being a newbie and viewing this from the newbie lens I thought this would be pretty plug and play (because like, why not), and it is to some degree but there is some formatting that has to be done. I really wish this was in the product documentation, as it would've saved me a couple of hours, but now you know. Here's a copy of the payload straight from Block Kit Builder:


{
    "blocks": [
    {
        "type": "section",
        "text": {
            "type": "plain_text",
            "text": "This is a plain text section block.",
            "emoji": true
        }
    }
]
}

Notice everything is wrapped in braces, and there's the "blocks": array. I believe ServiceNow is already wrapping this for us and if you copy and paste this straight in you'll get an invalid_block_format error from Slack. If you are troubleshooting this will be found somewhere in the Steps section of your execution. What I've found works is condensing it down to one line (thank you Earl Duque, here's a neat tool):


var block = '[{"type":"section","text":{"type":"plain_text","text":"This is a plain text section block.","emoji":true}}]';
return block;

I've removed the outer curly braces and the "blocks": portion. I then declared my JSON with a variable and wrapped it in a string and finally returned the variable I created. This is a pretty basic example and just has plain text but a good test snippet to make sure your flow/block is working. Here's an example of using the block code above and using a test execution in Flow Designer:



You can see my name is what I put in the Post Message Username field, and it's using the emoji I set rather than the black and white icon associated to the app. I really like the markdown sections and dividers you can use in Blocks so I'll expand more on what I did for my Outage app. I did add a few more custom emojis (:exclamation-circle-solid: :minus-circle-solid: :info-outage-circle-solid:) into my instance here that I'll be calling out for each outage type. I found a cool tool that allows you to take the free Font Awesome icons and convert them to png to do this.


Here's the code snippet i'm using and will be using for each outage type, basically changing the icon and text in the first markdown section. I do want to mention my Details field is read only and has some HTML formatting so the regex shown is to strip out the HTML tags used for formatting and replace them with newlines since we're using Markdown. This is a good time to mention that you can't use HTML in Slack Blocks and if you want do formatting you have to use Markdown.


What's really neat is you can take this payload and reverse engineer it into the Block Builder Kit to see how it will look, so lets say you made some modifications to the code and want to visualize it just pop it into the payload field:


var instanceURL = gs.getProperty('glide.servlet.uri');
var ci = fd_data.trigger.current.getDisplayValue('cmdb_ci');
var ciId = fd_data.trigger.current.cmdb_ci;
var sysId = fd_data.trigger.current.sys_id;
var number = fd_data.trigger.current.number;
var shortDesc = fd_data.trigger.current.short_description;
var begin = fd_data.trigger.current.begin;
var end = fd_data.trigger.current.end;
var details = fd_data.trigger.current.details;
details =  details.replace(/(?:<br(\s*\/)?>)|(?:<p>)/gi, "\n").replace(/(<([^>]+)>)/ig, '');
var url = instanceURL + 'sp?id=service_status&service='+ciId;
var block = '[{"type":"section","text":{"type":"mrkdwn","text":":exclamation-circle-solid:  *Outage*: <' + url + '|' + number + '> ' + ci + '"}},{"type":"divider"},{"type":"section","text":{"type":"mrkdwn","text":"*Details History*"}},{"type":"section","text":{"type":"plain_text","text":"' + details + '","emoji":true}},{"type":"divider"},{"type":"section","text":{"type":"mrkdwn","text":"*Status*"}},{"type":"section","text":{"type":"mrkdwn","text":"*Begin* \n ' + begin + '"}},{"type":"section","text":{"type":"mrkdwn","text":"*End* \n ' + end + '"}}]';
return block;


Here's the Outage from the code snippet above, and I'll show the Degradation and Planned Outage screenshots as well:





The last thing I want to note is that the URL will redirect the user to the System Status page of the Service Portal:



Takeaways


I covered the very basics here of sending blocks to Slack. There's so much possibility with the Slack spoke especially when it gets into interactivity but there is a learning curve in my opinion. As I wrote this article I thought about the different ways I could script bot names or emojis as icons depending on the outage type and how I could check the system property for my instance and set Channel IDs based on that for testing purposes, i.e. if I'm on Dev then send to a testing channel. I hope this post provided some good tips on getting started on the basics and making things look nice in the mean time rather than just sending a plain text message.


I personally want to expand more into interactivity, i.e. having buttons instead of links but didn't make it there for this use case quite yet. The product documentation does cover setting up interactivity to point to a Scripted REST API and covers shortcuts somewhat, but the documentation hasn't really gone into detail on handling block actions, and for some reason I couldn't get past the 401 error thrown by the Scripted REST API when clicking a Link Button to open the outage in the Platform view while using the OAuth method for the spoke but this could be something in the set up I missed. There is product documentation out there for outbound and inbound configurations, modals, decision tables, etc. but that's for another time. If you have any Slack Spoke resources please drop a comment below. I plan on putting out more articles on the Slack Spoke as my use cases and knowledge of the Slack API grow.

503 views0 comments