Mandatory configurations before migrating from Service Portal (SP) to Employee Service Centre (ESC)
Employee Centre (ESC) portal is the trending portal these days because of its unique features. Many of the customers opt to migrate from the traditional Service Portal (SP) to the ESC portal.
Migrating to the ESC portal needs to configure some OOB functionalities, system properties, etc.
Here are a few observations from my recent experience of migrating to ESC from SP to one of our customers.
1. Default Portal:
OOB the default portal is “Service Portal”. We should change this to “ESC” so that survey notification links will be redirected to ESC. (Ref: Now Community)
Steps:
- Navigate to “Service Portal > Portals”.
- Find and open ESC Portal record.
- Check the “Default” checkbox. (If not available on the form, add it to the form)
- Save the record.
2. System Properties:
There are a few system properties, whose value is “sp” that will be used in scripts for redirecting to the service portal when clicked on any hyperlinks in Notifications, Portal Pages, Virtual agent, etc.
Replace the value of the following system properties from “sp” to “esc”.
- sn_itsm_va.com.snc.itsm.virtualagent.portal_url
- com.glide.cs.portal_url_mapping.portal.kb_knowledge
- com.glide.cs.portal_url_mapping.portal.sc_cat_item
- sn_now_teams.portal.suffix - This property should be changed if you are integrating Microsoft Teams with ESC portal.
Change these values to ‘esc’.
3. Automatic Portal Redirection upon ESS user's login:
Initially, I thought of replacing “/sp” with “/esc” in the initialize() function of the “SPEntryPage” script include. But this is not the right solution to permanently redirect to ESC if the URL contains “/sp”.
Redirecting is possible with a small workaround! You could add a JS Includes on a Theme record that is associated with the specific Service Portal you want to redirect. JS Includes will be loaded in an attempt to display every URL. Within the JS Includes record, you can create a UI Script which makes redirection possible using the JavaScript object “window.location”. (Ref: Community Article).
a. Navigate to “Service Portal > Portals”.
b. Open the Theme record of the Service Portal (sp). - In my PDI it is La Jolla.
c. Go to “JS Includes” section and create a new JS Include.
d. Create a new UI Script.
(function () {
window.location.assign("/esc");
})();4. Controlling the visibility of Knowledge Article/Catalog items accessed via Taxonomy topics:
Though KB articles/Catalogue items are controlled visibility/access to the right users by the user criteria defined on the Knowledge Base are limited to the Knowledge Portal page only. Users without the right roles still have access to KB articles/Catalogue items via taxonomy topics.
- Under taxonomy topics, KB articles/Catalogue items are added as a content item, hence they are accessible to everyone who can access the taxonomy topic.
- To restrict this, add required roles to the ‘Roles’ field on the catalogue item form.
- There are two fields at the Knowledge Article level that references User Criteria:
- can_read_user_criteria (Can Read)
- cannot_read_user_criteria (Cannot Read)
- It is not possible to add a role to the “Can Read” field without checking out the KB article. This can be achieved through the “Fix Script” if you have multiple KB articles to be modified.
Finally, replace the “/sp” with “/esc” wherever hard coded in the email scripts or any server scripts.
Above are my observations from my recent experience. Please correct me if I’m wrong anywhere. Also, add the suggestions you have observed from your experiences.
All the content I have added here is referenced from various community posts and articles. I thought of putting it all together to provide a single spot to the users.
