Change "incident_take_me_to_the_incident" so that it will redirect properly

[priisholm]

Hi guys

I have a small issue - maybe you can help me..

I need an email scripts the will redirect the user (enduser or itil) to the correct place (Service Portal or backend)

Therefore I made 2 versions of the email-script "incident_take_me_to_the_incident" with different redirections:

1. incident_take_me_to_the_incident_enduser (var link = '/sp/?id=ticket&table=incident&sys_id=' + current.sys_id + '&sysparm_view=portal';)
2. incident_take_me_to_the_incident_itil   (var link = current.getLink(); )

Assume someone - by accident - adds the enduser to the watch-list (and they actually did), so now the enduser will get a mail (nr.2) with updates on the ticket, and the button will link to the backend.

Is there a way to avoid this??

Can I somehow identify which user that will receive this mail... I guess that the script is only running 1 time pr. notification

Another solution could also be, that its not possible to add endusers to watch-list ... 😕

or...

Thanks!

Soren

[Stephen Farrar]

Hi Soren,

I wonder if you've considered configuring redirect to service portal upon login for certain types of users, so if they don't have a role they automatically get sent to the portal?

You can find more information at the following links:

Redirect to Service Portal after login

Service Portal Single Sign On, logins, and URL redirects

Configure the Service Portal login page

Hope that helps,

Stephen

[priisholm]

Hi Stephen

We actually did this and it works too but not always for links from notifications.

But yesterday I did some more experiments - and it turned out that if the user clicked "Remember me" on the Service Portal, and just close the browser - the "Remember me" cookie in the browser, will redircet the enduser from the (wrong) notification-link to the backend... If the enduser didn't use "Remember me" or logged out from the Service Portal and then used the notification-link - he is redirected to the SP and is forced to login and therefore ends up in the SP.

We cant do anything about the cookie - so if this should work 100% correct, we should limit the users on the watch-list to only show internal users (so no accidents will happen). But I don't know what to do about those that are already sent out - except for closing the specific incidents where it happened or make some changes to SPEntryPage....

BR

Soren

[Stephen Farrar]

Hmm, ok well another approach is to build your own notification trigger using events, rather than the built in table / conditions mechanism.

Essentially you would create a new event. Fire that event when you want to send out the email. When you fire the event you would include the recipients in the event parameters.

In the code where you fire the event, you fire the event one time for each recipient, you can then include the appropriate URL in the second event parameter.

So possibly you would have:

Business Rule - fires on the condition that is intended to generate the email.

* Calls a script include method, that script include would build both required links, then for each recipient, generate an event with that recipient, and the link as parameters.

** You could also check here for your list of recipients if they're an 'end user' but they've been added to the watch list, and only generate the event with the SP link as required.

* Then your notification stays the same, but fires off the event, and includes users from the event parameters - rather than the field on the record.

All this assumes that you have some way of figuring out whether a user is an end user or something else - maybe a simple check whether they have any roles could work.

Hope that helps

Stephen

[Troya1]

We still can't get around the welcome screen.

Once the user clicks the email link, logs into the portal (for the first time), it takes them to the welcome.do page. If you click BACK, the incident is pulled up. 

Have not figured out how to bypass this welcome screen after portal login to see ticket.