Service Portal Redirection: Take Me To The Incident Button

[Kyle Krick]

I am currently configuring Service Portal redirection according to this post: https://community.servicenow.com/community?id=community_blog&sys_id=cbcda2e9dbd0dbc01dcaf3231f961949 And I have left the redirection in that SPEntryPage script include alone (meaning, if the user has roles, go to Platform UI/nav_to.do and if they have no roles, then they get the Service Portal equivalent). I followed that guide and it works (almost) perfectly.

The issue I have is with the "Take me to the incident" button generated in the Email Script "incident_take_me_to_the_incident." By default, it links to https://[domain].service-now.com/incident.do?sys_id=[sys_id]. This will send the user to the Platform UI, but does not have the left navigation, since nav_to.do is not part of the URL.

Now, if the user goes to the Service Portal directly to check a ticket (whether by the Incident widget on the home page or using the requests page) they will go to /sp?id=ticket&table=incident&sys_id[sys_id]. This is an inconsistent user experience as the two forms are very different. To make the experience even less consistent, if a non role user gets a platform ui link that includes nav_to.do, then they will get sent to /sp?id=form&table=incident&sys_id=[sys_id]. This link is generated in SPEntryPage with the call to new GlideSPScriptable().mapUrlToSPUrl(redirectURL); on line 99. 

What I would like is for the "Take me to the incident" link to:

1. For the caller (whether they have roles or not):

go to the service portal with link sp?id=ticket&table=incident&sys_id[sys_id].

2. For the assignment group/assigned to/work notes list/watch notes list:

go to the platform UI with link nav_to.do?uri=incident.do?sys_id=[sys_id]

To do this, I added the following check:

if (email_action.recipient_fields.contains("caller_id")) {
  link = "sp/?sys_id=" + current.sys_id + "&view=sp&id=ticket&table=incident";
} else {
  link = "nav_to.do?uri=" + link;
}

Now, this works pretty well, but it also has issues I cannot think of a solution to.

For example, if the caller gets added to the watch notes list they will get two emails, the one with the service portal link and one with the platform ui link. (Obviously this is not desired and is discouraged, but it does happen quite often with itil/process users who don't understand how it works.) Now, if the caller has a role and clicks the platform ui link, then they go to to the platform ui link (not desired, if you are the caller we want you going to SP no matter what). If they have no roles and click the platform ui link they go to the /sp?id=form&table=incident&sys_id=[sys_id].

Another issue related is if any non-role user gets added to watch list, then they get the platform ui link and get redirected to /sp?id=form&table=incident&sys_id=[sys_id].

Having written this all up I now wonder if perhaps the mapUrlToSPUrl() function needs to be updated to fix this...

Consistency is key and unfortunately I can't think of a way to deliver it.

I've attached screen shots of the four different possible incident views to show the issue.

[SanjivMeher · Accepted solution]

I think you need to bring some consistency to the notifications you are sending to the end users.

If a user is a caller or part of a watch list, they should always receive email containing link to the portal only.

If the caller is added to work note list, I am just trying to think of a scenario, when this happens?

Why would a caller be added to work note list? He should only receive comments and not work notes.

You should restrict a caller from being added to a work note list. If he/she is an ITIL user, he/she can anyway have access to view the notes in the portal as well.

[Kyle Krick]

Hi Sanjiv,

You would be correct... the inconsistency is sparked by customizing the Incident notifications. I just discovered that my company's email notifications for incidents have been customized and differ greatly in the targeted audiences as compared to an OOB instance. If we revert the audiences, this should be a non-issue and I can use the fix to the button that I described above.

[Kyle Krick]

I've also discovered an additional solution by using page route maps. You can create page route map from page id "form" to route to page id "ticket." This way, no matter what, the user gets directed to the newer (and nicer) ticket page on the Service Portal.