Determine Service Portal Suffix that Request was generated from - Required for dynamic link in notifications

[Brent Sutton]

Hopefully, this is a simple question.

We have multiple Service Portals that generate requests to our fulfilment teams. These requests use shared email notifications with links to the request - the OOB notifications are set up with ${URI_REF} which takes them to the backend platform. This is undesirable as we want our customers communicating via the portal.

I'm trying to create a dynamic email script that recognises the request's origin (i.e. service portal suffix) and generates a link to the ticket in the respective portal. Is there a way to determine which portal the request came from or is there another method to direct them to the correct portal?

So far I've looked at sp_log which has a reference field to the portal but this is blank for "Task View" log type which is the one that contains the task sys_id in the ID column. I could cross-reference the Session ID to look at other log types, from the same session, that do contain the portal id but it seams like there should be an easier method.

I also thought there may be a way to parse the URL from a client script and store the portal suffix in a temp variable or custom field on the task table. Not sure is anyone has gone down this path in the past and found a working solution?

Any suggestions on how best to approach this would be much appreciated.

Brent

[sachin_namjoshi]

You can simply use $sp.getValue('url_suffix') on server script of the widget.

This will give you URL suffix and then you store this in a system property.

Your email script can user get Property to get portal url.

If you don't want to use sys property, then you can create a custom lookup table with above method to store RITM sys_id and portal prefix. Your email script can query this look up table to generate notification URL.

Regards,

Sachin

[Brent Sutton]

Hi Sachin,

Thanks for coming back to me.

I was trying to avoid creating custom widgets just to return the portal suffix. Was after something less invasive using information that was already in the system or easily obtainable on a per request basis.

I'm working in a method using sp_log but was hoping I was missing something. We can't be the only ones, using multiple portals, with this issue?

Brent

[Petr Pastuszek1]

Hi,

we run into same issue

2 portals

- /a

- /b

When creating ticket in '/b', we would like to have in email notification URL towards portal '/b'

Has anyone solved this somehow?

/Petr