Creating Requests from Connect Chat

[Tim Provin]

The Problem

I recently had a customer ask for the ability to create a Request from the Connect Chat client, and spent many hours digging for a solution.  Multiple people provided details into how the Chat Actions work, and possibilities for how it may be accomplished.  While looking through the solutions I realized that they were missing the flow that users are used to when ordering items from the catalog.  I didn't want to be limited to hardcoding specific catalog items into the Chat Action and using the CartAPI which would require a single Chat Action per catalog item. In my world, working harder is never an option.  I should be able to go from Chat directly to the Service Catalog, submit a request for the user that I am chatting with, and have the Requested Items returned to the chat window without having to spend a large amount of time reentering the same information.  So I went on a mission to come up with a solution that would provide what I felt was a seamless solution.

The Solution

By using Session variables, and the functionality that Connect Chat provides in the Create Incident Chat Action, I was able to provide the desired outcome. 

First, we create a Chat Action that will populate the necessary variables about the chat session into the GlideSession variables.  It will then use the response.newRecord functionality to direct the user to the Service Catalog homepage.  While this isn't the intended functionality of response.newRecord, it serves the purpose for directing the user to the Service Catalog without refreshing their screen.

We are storing 4 Session variables in my situation.  First is the conversation.document.opened_by.  This is the user that initiated the chat session, and we use this because we populate a Requested For variable on our catalog items using this variable.  The next three variables are all needed for knowing which chat session we will be sending the link to the Requested Items back to, and how we populate the record card.

var grProfile = new GlideRecord('live_profile');
grProfile.addQuery('name', gs.getUserDisplayName());
grProfile.query();
if (grProfile.next()) {
	profileID = grProfile.getUniqueValue();
}

var session = gs.getSession();
session.putClientData('chatReqFor', conversation.document.opened_by);
session.putClientData('chatConversation', conversation.sys_id);
session.putClientData('chatGroup', conversation.document.group);
session.putClientData('chatProfile', profileID);

response.newRecord("catalog_home.do%3Fv%3D1%26sysparm_catalog%3De0d08b13c3330100c8b837659bba8fb4%26sysparm_catalog_view%3Dcatalog_default%26sysparm_view%3Dcatalogs_default", {

	
});

The next step in our process is to get the session variable for our Requested For into the catalog item that we are populating.  Because we are using a variable set that contains the Requested For variable, I only needed a single Catalog Client Script against that variable set.  I created an onLoad Catalog Client Script to pull in the data from the session.  Simple process, but thought I would share.

function onLoad() {
	
	var reqFor = g_user.getClientData('chatReqFor');
	if (reqFor)
		g_form.setValue('requested_for', reqFor);
	
}

The final step in the process is getting the information back to Connect Chat from the newly submitted Requested Items.  This was done by creating a Business Rule on the Request table.  You may be asking yourself, why would we create the Business Rule on the Request table?  There is one main reason for this, and I have had people argue this process with me multiple times.  ServiceNow creates all of the Requested Items that are ordered before the Request is created.  Because of this, the end user does not have access to their Requested Items at the moment they are created and if we sent the record card back to chat it would show as inaccessible due to security.  Waiting until after the Request is created negates this issue.

I created my business rule to run after insert at an order of 10000.  Is this the most appropriate timing for it, I don't know but it works.  The condition on the business rule checks to see if there is anything in the Session variable for the conversation.  We don't need to have it run if we aren't coming from the Chat Action that we created earlier.

gs.getSession().getClientData('chatConversation') != ''

The business rule itself will query the Requested Items and build the data object needed to generate the record card for each, and send the card back to the chat conversation.  Once it is completed it will clear the session variables so that we don't get confused with multiple chat sessions that a user may have.

(function executeRule(current, previous /*null when async*/) {
	
	var session = gs.getSession();
	var conversation = session.getClientData('chatConversation');
	var group = session.getClientData('chatGroup');
	var profile = session.getClientData('chatProfile');
	
	var gr = new GlideRecord('sc_req_item');
	gr.addQuery('request',current.getValue('sys_id'));
	gr.query();
	
	while (gr.next()) {
		
		var linkUrl = "/sc_req_item.do?sys_id="+gr.getUniqueValue();
		var linkName = gr.short_description;
		var msg = "@L["+linkUrl+"|"+linkName+"]";
		
		var data = {
			message: msg,
			group_id: group,
			from_profile: profile
		};
		
		//add link if we have a valid one
		
		if (linkUrl) {
			data.links = [
			{short_description: linkName, url: linkUrl}
			];
		}
			
		new LiveFeedMessage().postMessage(data);
			
	}
		
	session.clearClientData('chatConversation');
	session.clearClientData('chatGroup');
	session.clearClientData('chatProfile');
	session.clearClientData('chatReqFor');
		
})(current, previous);

The Caveat

There is one major downfall to how this functions, and the fact that we have hijacked the response.newRecord back in the Chat Action. That is we are unable to use this functionality if the agent is using the full chat session in a flyout.  The reason behind it is that the flyout window ($c.do) is looking for a record view to display, but we are not displaying an individual record.  

Closing

Until the time that ServiceNow opens up the $c.do page for configuration, we will be using this solution and directing agents to use the sidebar for Connect when needing to open a Request.  They can use a combination of both the flyout and sidebar, or whatever works best for the agent.  I hope this helps someone achieve the results that they are looking for. Thank you for taking the time to read.

[The SN Nerd]

Great article, has helped me work out how to get a URL card to show for records transferred from New Call.

Did you manage to get the Connect Chat conversation into the RITM comments?

[Tim Provin]

Paul,

Glad this helped you out.  I did not look at getting the chat conversation into the RITM.  It may be possible to pull that information in a business rule prior to populating the card back to the chat window.  That said, I haven't looked at the connect support functionality in a couple releases, so I don't know what might have changed to break or help this process.  

[The SN Nerd]

I got this all working fine...

Until I test as non-admin.

Then it inexplicably does not work.

Did you come across this? I'm dumb founded.