While most IT departments do their best to educate their end users and help them to solve their own problems as they come up, the need for users to contact the Service Desk is something that will always be there. Ideally, this contact takes place through a support tool like Service˜ow but chances are you’ve still got users who will contact the Service Desk directly by phone. As a result, Service Desk agents spend a lot of their time taking calls and logging tickets for those calls.
One of the challenges that I’ve seen a few times before with this type of arrangement is that people will call the Service Desk and start explaining who they are and what their problem is but the Service Desk agent doesn’t know if the end result of the conversation is going to be an Incident ticket or a Service Request. The way most of the forms in ServiceNow are set up requires you to make a determination about the type of ticket before you can start logging details about that ticket. As a general rule however, the Service Desk really needs to start recording the Caller information and the details of the call before they determine what type of ticket needs to be logged.
I worked with a co-worker of mine (Brad Hicks) to create the New Call application to help solve this problem. This custom application has been used by quite a few customers since as a standard Professional Services offering and has even made a couple of appearances at the ServiceNow ‘Knowledge’ conferences. I’ve been meaning to document the solution for a while and capture it in a redistributable update set. At long last, here it is!
The New Call application is really a simple solution. It uses standard ServiceNow forms and scripting techniques. Most of the functionality is included in a single ‘Route’ UI Action button that directs the call to an Incident or a selected Request Item in the Service Catalog. The ‘Incident’ option works just like other options in ServiceNow that generate one record based off of the contents of another. It simply creates a new incident record and copies the field contents into that incident record.
The ‘Request’ option routes the call to the corresponding Service Catalog entry form for the selected catalog item. The ‘Route’ UI Action contains logic to store the contents of all of the fields in URL parameters that get passed on to the catalog item. Because these parameters get passed over the URL (and there’s a limited amount of character space available there) I’ve also included a character counter to limit the number of characters that can be input into the ‘Additional Comments’ field. Full documentation on the character counter can be found here.
Each catalog item that you want to use with the New Call functionality needs to have corresponding variables and client scripts to accept these parameters and populate them into the item. I’ve included a catalog client script – ‘Populate New Call Info’ and associated it with the ‘common_comments’ variable set. You can use this variable set and client script on any item you wish to use ‘New Call’ with.
Usage:
Related Links:
- Download: New Call Application
- Supporting Documentation: Installing an update set on your instance
Thanks Mark for this. You are absolutely right, this is requested by a lot of customers and it’s great you put it together in an update set!
I think it’s an excellent base, and I see great opportunities to extend the call types to change request (and route directly either to the change_request or to record producers).
Excellent
I agree. I’ve thought about putting change requests in as well, but the way clients handle this scenario typically varies. Some may want to create a change request similar to the way it creates incidents. Some may want to route to the service catalog similar to the way it creates requests. Some may want to set up change templates and copy from an existing change. If anybody comes up with a good, consistent way to add this behavior then I’d love to look at it. In the meantime, this is easily configurable to meet those needs.
Hi
This is really good, I know its been around a while. I have a quick question regarding this, once it redirects you to the incident, the incident is already saved to the database, so if a user decides to either go back using Internet back button or the green back arrow in Service Now. The Incident has already been created but all the mandatory fields are empty, is there anyway round this at all?
Kind Regards
David
This is possible by modifying the incident creation portion of the UI action script. The basic idea is to take the input from the fields on the form and construct a URL to route to. The URL string will use ‘sysparm_query’ arguments to auto-populate the fields on the form…without saving the record to the database. See this post for an example.
Populate Default Values from a URL
Thanks for the information, got this working within the UI Action using the following URL
Awesome. You should also consider removing the ‘https://XXX.service-now.com’ portion of that URL so that you’re using a relative link if you haven’t already. That way it won’t break when you move to different instances.
Mark,
Does the solution work for bundles?
It looks perfect for Catalog items.
Regards,
It should work for anything in the catalog that can use variables and client scripts. I would advise you to move away from Bundles though. Order Guides have been the preferred method over bundles for about 3 years now.
Yes sorry I meant Order Guides, like the ‘New Employee Hire’ one.
Then it’s perfect! Thanks.
I’ll have a go.
Mark,
Is it possible to launch the Incident form but not have it saved? The issue is that the Incident is being saved without the proper routing etc..
Yep. This is possible by modifying the incident creation portion of the UI action script. The basic idea is to take the input from the fields on the form and construct a URL to route to. The URL string will use ‘sysparm_query’ arguments to auto-populate the fields on the form…without saving the record to the database. See this post for an example.
Populate Default Values from a URL
Mark,
In regards to Order Guides when I select the New Employee Hire in the Request Item field the Submit button seems to redirect me to an order form for the New Employee.
I can’t see a way to order the items which are part of the order guide. For instance if the new employee needs an Iphone it doesn’t take me to the Iphone screen to put the info about the iphone.
Can you assist please? What am I missing?
Looks like there is an error in the ‘Submit’ UI action code on the ‘New Call’ form. You can fix the issue by updating the UI action code. There is a single instance of ‘u_item’ in the script that should be ‘u_request_item’ instead. I’ve updated the update set with this fix as well.
Thanks Mark. I miss your previous comment where you already mentioned that.
Works great.
If anyone is interested here is what I ended up with, %0d is a carriage return in the description field.
Hi Mark,
Can you explain how the client script ( Populate New Call info) for the Demo Item works? I tried to add a new variable to the demo item called “requestFor” with the question “Requested for” and tried to populate it with the u_requested_for information from the New Call app. The reason being is that ‘Requested for’ will be a common question on any S request. I see that the info already propogates down to the cart item and task. I do have another way around this which includes leaving it off the demo item when submitted via the New Call and having it visible only when it is submitted via the Service Catalog. This is how I amended the ‘Populate New Call info’ client script:
Anyway, thanks as always, Mark S.
function onLoad() {
//Populate the variables with the parameters passed from New Call module
//Requested for gets populated in the cart by the New Call Submit UI Action so no population is necessary here
var loc = getParmVal(‘sysparm_location’);
var comments = getParmVal(‘sysparm_comments’);
var requestFor = getParmVal(‘sysparm_requestFor’);
if(loc){
g_form.setValue(‘location’,loc);
}
if(comments){
comments = decodeURI(comments);
g_form.setValue(‘comments’,comments);
if(requestFor){
comments = decodeURI(requestFor);
g_form.setValue(‘requestFor’,requestFor);
}
}
}
function getParmVal(name) {
name = name.replace(/[\[]/,”\\\[“).replace(/[\]]/,”\\\]”);
var regexS = “[\\?&]”+name+”=([^&#]*)”;
var regex = new RegExp(regexS);
var results = regex.exec( window.location.href );
if(results == null){
return “”;
}
else{
return results[1];
}
}
The first thing you need to make sure you’re doing is to pass the ‘u_requested_for’ value from the ‘New Call’ form. You should be adding this to the URL in the button logic on the New Call form. If you’re already doing that, then you also need to make sure your catalog client script is set up correctly. I see one line that might be causing issues that should be removed…
comments = decodeURI(requestFor);
Thanks for the response. I was pulling in the wrong sysparm value in the client script. Its should have read ‘var requestedfor = getParmVal(‘sysparm_user’);’ and I was using”var requestedfor = getParmVal(‘sysparm_requestedFor’);
Then added the following to the client script:
if(requestedfor){
g_form.setValue(‘requested_for’,requestedfor);
where “requested_for” is the new variable on the SC item. I hope this helps anyone else who uses this app and is a like me…not to savvy at scripting.
I have been playing with this for a while, one of the problems I have encountered is with the update set having 2 errors in the preview log, has anyone else encountered this? I just tried it twice on demo18 with the same result. Cheers
Mark, thanks for the feedback. The good news is that neither of those preview errors affects the functionality at all, so you should be okay using what you’ve downloaded. I’ve modified the update set, but it looks like the latest version of SN has some sort of issue with the update set preview. I’m still seeing one error, but you can safely ignore it for this update set.
When using the New Call app. the ‘requested_for’ information is passing nicely down to the tasks. But I do find that if you submit the same request NOTusing the New Call app., the ‘requested_for’ (on the corresponding RITM) is no longer populated from the catalog item. So, not being the code jockey I would like to be, there is a client script to do this for me which is attached. My issue now is that there seem there may be a little conflict between this client script and the ‘populate_new_call_info’ cs.
As an example; add a new variable called ‘requested_for’ to the New Call item (demo) request.
Submit the request on behalf of another user. (not the logged in user).
When you order the item, the corresponding RITMnnnnn will still show who the request was actually made for.
So somehow you may have to modify the attached client script to signify whether the request was initiated by the ‘new call ‘ app or not.
There is another business rule option in this article (http://community.servicenow.com/node/1001434), which works, but i think I may come up with the same conflict.
I will post my findings, but I hope this helps any of the many users of this app, and if you have an alternative, I’d love to hear it. Thanks again for the post. Mark S.
// was used on our test sc item for change request
// use as a catlogue client script on the item in maintain items
// name is Populate requested for to Cat Item
//Applies to – variable set
//Type – onChange
//Variable set – variable set that contains the requested_for variable
//Variable name – requested for
//You are going to have to modify this to signify if this is from the ‘new call; app or not.
function onChange(control, oldValue, newValue, isLoading) {
if(oldValue != newValue){
var uid = g_user.userID;
var rf = newValue;
// alert(‘ReqFor = ‘ + rf + ‘ Logged User = ‘ + uid);
setReqFor(uid,rf);
}
}
function setReqFor(uid, rf) {
// alert(‘in Function :: ReqFor = ‘ + rf + ‘ Logged User = ‘ + uid);
// var answer = false;
var rfr = new GlideRecord(‘sc_cart’);
rfr.addQuery(‘name’, ‘DEFAULT’);
rfr.addQuery(‘user’,uid);
rfr.query();
if(rfr.next()){
rfr.requested_for = rf;
rfr.update();
// answer = true;
}
return;
}
Mark,
It appears that the client script “Hide buttons from new call” on this table no longer functions as expected in Berlin.
I have installed the update set in the demo08 instance to make sure our instance was not ‘special’ and the submit button still appears.
In our case, we are removing all but the new call submit and it is causing the first field on the form to be displayed in the form title bar.
//Remove all buttons except for the ‘Submit’ button specific to the ‘New call’ form
if (refs) {
for (var i=0; i < refs.length; i++) {
var ref = refs[i];
var inner = ref.id;
if (inner != 'new_call_submit'){
ref.style.display = 'none';
}
}
}
I was originally going to just name the additional UI action we needed to hide in the script, similar to how you have it setup currently, but realized that script is not working in Berlin.
Any tweaks we need to do to correct this??
That is really strange. It seems like in Berlin they’re adding some extra buttons as spacers or something. These buttons don’t have ID values so you can identify them and skip the hide for them. Try a script like this instead. Just change ‘route’ to the action name of your button.
var items = $$('BUTTON').each(function(item){
if(item.id != 'route' && item.id != ''){
item.hide();
}
});
We have a sandbox instance which we just upgraded to Berlin. I too notice the ‘route’ button is now ‘submit’. Also, I notice the topmost field (in our case the’requested-for’ field) is 90% hidden. Strange.I’ll update if I can find anything
I reapplied an update set I had all my new call stuff in from our dev instance, and it seems to have returned our sandbox back to normal, but definitely something to watch out for when applying Berlin to our other instances.
Thanks Mark. This actually came up in a previous comment. I’ve updated the update set to fix the issue caused by Berlin.
We have applied your update set to our sandbox instance, but the form is only visible to admins.
Non-admins see just the Route button and literally nothing else.
Most of you module references forms that non-admins would be able to see normally.
All the views and roles look fine and other above seem to use your module without any changes.
I also applied it to one of the demo instances (https://demo14.service-now.com), and I still couldn’t get it to work.
What have we missed?
@Richard,
I apologize for the issues with the New Call update set. The problem you’re experiencing is caused by the change from default allow to default deny security. You can fix the issue by creating three new row-level ACLs, one each for Read, Write, and Create, so that the ‘itil’ role has full permissions on the ‘New Call’ table for all operations.
I just completely rebuilt the new call update set (and posted it in place of the old one) to fix this issue and a few other ones that I noticed while going through the code. I would strongly recommend you back out the update set you just applied if you can and then download and apply the new version.
@Mark, I have applied the updated set per your recommendation and it worked immediately.
This will please all our service desk staff. Thank you hugely.
Would be really nice if the new call wizard allowed you to see any incident and request history of the user to keep from creating duplicates. I tried adding the related incidents button via adding ref_contributions=user_show_incidents to the attributes of the Caller variable reference and the Icon never appeared.
I agree Scott. The reason I haven’t done this is because of the way that ServiceNow has defined the ‘caller_id’ and ‘requested_for’ fields. Because one sits on ‘incident’ and one sits on ‘request’, there’s not a single field that you can key off of to pull up all of the information in one place. Unless you’ve promoted those fields to the task table, you need to set up two separate macros; one for incident and one for request, to pull up all of the information.
You can do that though, but you’ll need to make a copy of the ‘user_show_incidents’ macro and then adjust it accordingly. You’ll need to adjust the table and field being queried since the current macro just pulls them dynamically from the current table (incident). Using ‘u_requested_for’ and ‘u_new_call’ to query for the incidents and requests isn’t going to work in the new macro so you’ll need to hard code the incident and request table and field values in each macro respectively.
Instead of creating multiple custom macros, I created a Client Script to pass caller off to global search:
function onChange(control, oldValue, newValue, isLoading) {
if (isLoading){
return;
}
if (newValue == ”) {
return;
}
//Open the global text search and pass off caller
var caller = g_form.getReference(‘caller’, showCallerHistory);
}
function showCallerHistory(caller) {
var url = ‘textsearch.do?sysparm_search=’ + caller.name;
var w = getTopWindow();
w.popupOpenFocus(url, ‘related_list’, 950, 700, ‘ ‘, false, false);
}
Hello,
Just wondering which UI Action we need to modify. I am new to service now and not sure where to add the code that stops the new call from saving the incident on submit. Thanks!
It’s the ‘Route’ or ‘Submit’ UI action on the ‘New call’ table depending on which version you’ve got.
Thanks for the reply Mark. We tried to look for any UI Action called ‘Route’ or ‘Submit’, but did not see any listed in the system that were part of the “new_call” table. I believe our instance has the latest version of the Plugin.
I just updated to the latest update set and now I see the UI Action. Thanks for your help!
Similar to selecting a Request and picking from a list of available catalog items, is is possible to add a variable to select an Incident template and apply that to the Incident record that is created?
This is possible, but it would require a new field (to reference the template) and a change to the UI action. There is an ‘.applyTemplate’ function that you can use against glideRecord objects that you should be able to leverage when creating the new record.
Thanks Mark. I understand adding a new variable to capture the Incident template name. However, not sure where or what UI Action I would modify within the New Call wizard to apply the “selected” template. Any idea?
That depends on which version of this you’re using. If you’re using the ServiceNow wizard that was copied from the original, then there’s some sort of wizard script…but I don’t know what that would be. If you’re using the original ServiceNow Guru form-based solution described in this article, you need to adjust the ‘Submit’ or ‘Route’ UI action button on the ‘New Call’ table.
This post is a bit dated (2010), though some comments are relatively recent; so I’m wondering if this is still the best solution.
We looking into how to manage the inevitable ‘this should have been a request | incident’, and how to convert one to the other (and vice-versa), or if that is even a practical approach
Thanks in advance for your response
This is certainly part of the picture, and I know there are hundreds of ServiceNow customers using it. We still use it all the time for our clients at Crossfuze. It doesn’t do anything to solve the issue of something being mis-classified though. If it’s already in an incident ticket (via inbound email or something else) then the ‘New Call’ solution can’t do anything about it. We’ve created a ‘Request Link’ and ‘Generic Request’ functionality at Crossfuze that I think does a great job of solving this issue. These components are delivered as part of the Crossfuze Service Catalog turnkey solution (http://www.crossfuze.com/solutions/turnkey-solutions). I’d be happy to give you a demo if you’d like. Feel free to contact me here with a demo request.
http://www.crossfuze.com/contact-us
I would love to see the script for a metric that calculates Mean Time to Resolution that includes the time spent of a corresponding New Call. I’m attempting to write one but so far am unsuccessful.