Redirect To Requested Item (RITM)

[Kieran Anson]

TL;DR - An approach to redirecting to RITMs without implementing wacky customisations

A re-occurring theme in the community since ~Madrid is the ability to redirect to the RITM record when a request is submitted on the portal. Now, there are a number of solutions out there from a quick Google that enable this ability. However, they haven't sat well with me due to the level of customisation they introduce to the platform and I often just go down the route of educating users/the client on the request -> requested item -> catalog task process which sort of makes the question go away...sort of.

As a solution to the argument, the following Developer Share update set provides a configurable and best practice approach and avoids any need to clone widgets, create business rules etc to handle the redirection process.

So, how does it work?

An interesting concept I was introduced to whilst learning the Service Portal framework were page route maps which allow you to redirect when a page of your choosing is requested. This avoids any need to search through existing pages and widgets to find references and potentially have a poor user experience due to inconsistencies.

We also use a wrapper widget that contains no HTML but calls the normal catalog item widget using the spWidget directive. Whenever an item is ordered, this embedded widget emits an event we can listen to called $sp.sc_cat_item.submitted containing data on the created record and waits for a parent scope (i.e our wrapper widget) to handle the redirect.

Between the wrapper widget and page route map, we can do whatever we want when an item is ordered and have no worry about the dreaded customisation.

So, what does it do?

The setup will redirect to the RITM record based on the following:

1. The request has only 1 RITM
2. If the override property (x_295070_req2ritm.redirect_override) is set to true to redirect all RITMs regardless of record level configuration OR
3. If the Redirect to RITM field on the sc_cat_item record is true

Option 3 is where you have the power to configure the behaviour. For whatever reason, you might not want to redirect to the RITM for particular items, or potentially redirect to different pages by modifying the widget as part of this scoped app.

Redirect to RITM - Developer Share

[The SN Nerd]

I have the same sentiments as you!

My previous approach was to create a widget to redirect REQ to RITM that i place on the Request page.

This solution is much better.
Nicely done!

[The SN Nerd]

I'm seeing that it redirects to the Request ticket page rather than the Request Summary page if the REQ has more than one RITM or redirect is disabled for the RITM.

Is this by design?

[The SN Nerd]

I noticed it was actually redirecting multiple times.
I added in some IF statements and some code to redirect to the order summary page:

api.controller=function($scope , $location) {
	/* widget controller */
	var c = this;

	//$sp.service_catalog.cart.submitted - .request_method
	//$sp.sc_cat_item.submitted

	//SC Catalog Item widget emits an event when a record is succesfully submitted
	//Catch the server response and capture a redirect

	$scope.$on("$sp.sc_cat_item.submitted", function($event , $data){

		console.log($event);
		console.log($data);

		//Get Details on the RITM
		if($data.hasOwnProperty('table') && $data.table === "sc_request"){
			$scope.server.get({action: "get_record" , request_id : $data.sys_id}).then(function(response){
				console.log(response.data);
				//Only Redirect to ritm if
				//Global redirect override is enabled
				//Item is configured to redirect
				if(!response.data.error && response.data.ritm_redirect == "true"){
					console.log("Redirecting to RITM");
					$location.search("id=" + c.options.page_id + 
													 "&is_new_order=true&table=" + response.data.table + 
													 "&sys_id=" + response.data.ritm_id);
					return;
				} else {
					console.log("Redirecting to Order Status");
					$location.search("id=order_status" + 
													 "&is_new_order=true&table=sc_request" + 
													 "&sys_id=" +  $data.sys_id);
					return;
				}

			})
		} else {
			// Handle Record Producers
			if ($data.hasOwnProperty('redirect_portal_url') && $data.redirect_portal_url !== '') {
				console.log("Handle Record Producers");
				$location.url(data.redirect_portal_url);
				return;
			} else {
				// Fallback to a record
				console.log('Fallback to a record');
				$location.search("id=ticket&is_new_order=true&table=" + $data.table + "&sys_id=" + $data.sys_id);
			}
		}

	})
};

[Kieran Anson]

Oh good shout! I'll update the share with a new version. Thanks for the assist 😄 

[The SN Nerd]

Now that I have made those changes it is working perfectly!
I've recommended this solution to all my developers to solve this problem.

[JZX81]

Tried this out, doesn't seem to be working! 

[Kieran Anson]

Hi @JZX81 , sorry to hear you're having an issue. Unfortunately, I can't provide much aid with your comment - if you can provide some details I might be able to provide some advice.

[The SN Nerd]

I made updates to this for Agent Workspace redirects aswell.

[Utkarsh Sharma]

@The SN Nerd @Kieran Anson Hey I need help with the Agent Workspace redirects. I have a requirement to redirect to the RITM ticket when a certain catalog item request is submitted through Agent Workspace

[pespinar]

Hi @Kieran Anson ,

I believe your development should be quite useful. Unfortunately, it is not working for me. I am trying it in Employee Center (Utah), but I do not get redirected to the item, it goes to the usual request summary page. I have activated the page redirection, added employee center portal to portals list, enabled redirect to item in the item, and even set the property to true. But it still do not work. I am using 1.1 version. Could you help me on fix this?

Un saludo,

Pablo

[Grow2Dev]

Hello Pablo @pespinar ,

it seems, that you've done all the steps necessary, but since you seem to use the custom Page Route Map that comes with Kieran's Update Set, you might need to check two things:

1. The custom Page Route Map, where you've added the Emplyee Center to the "Service Portal/s" field, needs to be active.
   "Req2Ritm Redirect", sys_id "d3110c0f2f05f4501c43bed72799b67f"
2. You might have missed to deactivate the ootb Page Route Map Record 
   "HR Catalog Item", sys_id "9e25b4c97397130089b8e2596bf6a740"
   If this is still active, it will keep redirecting you to the REQ since they have the same order of 10.
   (Of course, you  can also adjust the order of the custom Page Route Map "Req2Ritm Redirect" to less than 1 instead.
   This works also, but deactivating the one that is not needed is better in my opinion)

This should fix your issue. 🙂

================================================
For all others, who land here and try to apply Kieran's solution for the Employee Center, you can follow these steps below:

After committing the UpdateSet you have a custom property and a custom field available.
You need to configure either the property (a) OR the specific catalog item (b) as follows:

(a) The system property 'x_295070_req2ritm.redirect_override' "allows for redirecting to RITM regardless of record level configuration"
(b) On the sc_cat_item table you will find a field 'Redirect to RITM' [x_295070_req2ritm_redirect]. If you set this to true, then you configure this specific catalog Item to be redirected to its RITM.
"Each catalog item can be individually configured to the request_item record rather than the order status/request page by toggling the Redirect to RITM field on the sc_cat_item form"

In addition you need to configure the record on the 'Page Route Map' table.

1.) In the 'Route from' column, filter for sc_cat_item

2.) variant a) In the 'ServicePortal' column, filter for 'Employee Center'

•  Open the ootb record (ootb short description should be "HR Catalog Item", sys_id 9e25b4c97397130089b8e2596bf6a740), but may differ if this has been changed on your instance). 
• In the 'Route to' field replace the value (ootb it is the 'esc_sc_cat_item' page) by the new 'r2r_catalog_item' page 

2.) variant b) In the 'short_description' column, filter for 'Req2Ritm Redirect' 

• adjust the custom Page Route Map of the Req2Ritm App by adding the Employee Center to its Portals list field
• important: deactivate the ootb Page Route Map, mentioned before in variant a), or adjust the order of the custom PRM to less than 10.

Note: If you may have changed several Page Route Map records that Route from 'sc_cat_item' or if you have added new ones for the Employee Center due to several testing approaches, make sure to revert those back or deactivate them, since they may interfere with this configuration.

If this is done your are good to go:
Go to the Employee Center and request the specific catalog item (if you just configured one item, where the 'Redirect to RITM' field has been set to true). After the submit, it should redirect you to the RITM. (If it still does not work on your instance, I recommend to try the steps on a fresh PDI and compare the configuration / artifacts, so you can fix the issues on your customized instance accordingly.)

Please note: for a quick second, the user will see the REQ page, but the redirect to the RITM definitely works.

In order to prevent this in-between redirect over the REQ and finally to the RITM, you may want to apply the described workaround by SN Nerd (Paul Morris) on ‎08-02-2021 above.

In the Client Controller section of the widget /nav_to.do?uri=sp_widget.do?sys_id=742a3bbe2fc1f4501c43bed72799b6de, adjust the section needed or, if you need it quick, just replace and copy paste the code from Paul Morris. Tried this and works just fine. After the submit the user gets directly redirected to the RITM 🙂

Kind regards 

[pespinar]

@Grow2Dev ,

thank you very much for your clarification in Employee Center. Now it is working perfectly on my side.

Un saludo,
Pablo

[CezaryBasta]

@Kieran Anson not sure if you're still supporting this, but how do you know which event handler will be triggered when $sp.sc_cat_item.submitted has been emitted - yours or the one from widget-sc-cat-item-v2? All of them?

I also don't understand why your solution isn't affected by the $location.search calls in the OOB widget after the event is emitted.

[Kieran Anson]

@CezaryBasta I've not looked at this for a while, I should probably update it with some of the "better ways" I've learned

Regarding the $sp.sc_cat_item.submitted event, the SC Catalog Item uses $emit which dispatches the event upwards to the scope parent (which in this case is my wrapping widget). Because we're also initialising widget-sc-cat-item-v2 with a propert of 'auto_redirect' false, we disable it's own mechanic of redirecting. If my wrapper widget did nothing, the page would simple stay as is. The key really is the 'auto_redirect' option passed in to the oob widget which disables the default mechanic 

[nosnibor]

This is a very sleek and clever way to get around this issue Kieran, thank you. It seems to be a little clunky when redirecting for some reason but apart from that it is spot on and my Manger liked it when I demo'd it. I hope you do continue to support it as it is the best solution out there in my opinion.

Thanks again.

[Waleska]

Has anyone been successful to get this working on the Service Operations Workspace? I want it to open up a new tab with the RITM record for our fulfillers who are converting Interactions into Requests.

With this solution, it's redirecting to the portal specific page which doesn't allow a fulfiller to edit the fields accordingly.

[TemporaryUserNO]

I'm also wondering the same question as @Waleska. We've successfully implemented the solution for Portal requests, but now we also need to have the agents be directed towards RITM after successful creation of a catalog item that have the same setting enabled (Redirect to RITM = true)

[Kieran Anson]

@TemporaryUserNO @Waleska I can investigate this and see if it's a possibility. Watch this space. 

[Waleska]

@Kieran Anson @TemporaryUserNO 
Thank you! On my end, we're exploring potential solutions as well by modifying the OOB widget to see if we can just easily redirect to the RITM. Will post here if we are successful.

[Sarah Travis]

@Kieran Anson

Thank you for this solution!  It worked great for us for non-HR items on our Employee Center.  However, when we try to submit an HR case, the Submit button grays and the form freezes like it's trying to redirect but never does.  The case is actually created, just no redirect.  I see this same behavior in my PDI.  

I tried turning off the global override, but that made no difference when submitting a case (or with anything else--as long as the page route map is active, the redirect occurs).  Any ideas?

[lucky024023]

Hello @Grow2Dev ,

I followed all the steps you have mentioned, but still i am redirecting to sc_request page and not my RITM page, could you help on this.

Thank you

[vidhya_mouli]

Very useful. Thank you for sharing.

[Ian Lee1]

@Waleska did you manage to find a solution to get this working for SoW? I am also in a similar situation