Incidents from the Live Feed? Heretics and selachophobes are at it again.

[slabodnick]

Last month I decided to embark on a challenge of seeing how the Service-Now Live Feed could go beyond just a social IT tool and really integrate into IT Service Management. This is actually something I've been thinking about for the past year and the motivation to make it happen was reignited during a conversation with Chris Dancy in which he described a day in which we would have the ability to create incidents, search knowledge, and perform several other functions through a social feed. Seeing as how Service-Now is an awesomely flexible tool, I knew this was my chance to really see what I could accomplish with social media. Besides, it would also have an added benefit of showing off, and I'm narcissistic enough to never miss such an opportunity.

To get started, I came up with a general architecture plan on how to build the integration with social media and ITSM. Since I knew this would be new functionality under the Social IT application, I decided to call it SocialQ. Please don't ask me the full details on why I settled on that name; I had to pick something to put in the Service-Now navigator and I decided to make a play off of "intelligent quotient." Great, I had a name. I knew I wanted to have a certain level of flexibility in this system so I took an idea from the gamification application I built into Service-Now as a general layout. I built a new business rule that would check against new messages in the Live Feed and, if conditions were correct, would then run "something." That "something" would be a set of scripts contained in the socialq database table. I hope you're catching on to what I'm trying to achieve. I don't want to have to modify business rules for every condition in the Live Feed; I'd rather have a single business rule and then manage the conditions and scripts in a separate section, which is listed under SocialQ under the Social IT application. This new business rule was aptly named "SocialQ_livemessage" and was designed to run when an insert would occur against the live_message database table. Of course, a general challenge came with trying to get the business rule to call another script while also passing values to it, but with the help of the Javascript replaceAll function, it could be done.

Great (again), I now had a general business rule that would run when conditions were correct, but what about those conditions? And what would run when conditions were correct? (Don't worry, I don't expect you to answer those questions — I'm building up the suspense). I created a new database table named u_socialq with certain data elements to house the information. The table contains fields such as name, a source table drop-down field, a condition field, and a script_plain data field to house the script that will run. One big caveat to building the module this way is that it's easy to have malicious scripts run on your instance. I very much, highly stress, and warn (whatever gets your attention) that you lock down the module under your Access Control List. Also, when testing scripts, do a lot of testing on your development or test instance before moving it to production (you've been warned). Keep in mind that the business rule I created, which already came from the previous gamification project, is designed to pull the conditions from the socialq record and use that to test against the message that was just inserted into the Live Feed.

From this point forward I was free to work on the socialq scripts to make things work. I will say that having knowledge of how the Live Feed builds messages is key to get things to work how you want. The reason is so when creating the socialq scripts, it's understood how to insert a reply message into the same thread (maybe I'll build a function for it) and to create links for the reference records. An example script I created was designed to create an incident from the Live Feed when anyone types "!incident" in a message (an idea from the infamous Chris Dancy). The conditions are simply when "message contains !incident" and the script will use the message as the incident subject, create the incident with the author of the original message thread as the caller, log the message thread history in the work notes, include a link to the message thread in the work notes, and post a reply in the message thread with a link to the incident. I also built the script to create a Live Profile for the incident so it can be followed as well as have a sys_popup display in the Live Feed. You can see a quick example of this on Youtube at http://www.youtube.com/watch?v=wXltl4UMJg4.

Additional scripts I've created include a (rudimentary) search in the knowledge base, and a way for people to join our gamification system by typing a command of "Join game" in the Live Feed. The nice thing about building the scripts in a separate module is that management is very easy. Inactivating scripts is as simple as opening the socialq record and unchecking the active value. Since modifying rules in Service-Now requires a change request to be submitted at my workplace, I now have flexibility to avoid major modifications to the instance.

That's it — a quick peek into my (crazy?) project of pushing the Live Feed beyond just communication. If you're wondering if I'm a heretic or selachophobe, I will state that I'll be at Knowledge 12 this year (http://community.service-now.com/blog/rglauser/servicenow-knowledge12-only-itsm-conference-selachophobes-and-hoarders). Any additional conclusions are your own, however I do think that lasers on sharks is a very bad idea.