HTTP 301 is a status code indicating that a resource has been permanently moved to a new destination – this is entirely unrelated to the topic we are about to discuss. When users log in to ServiceNow, they typically see role-based dashboards on the homepage, with the exception of ITIL agents directed to the Service Operations Workspace (SOW). But how is this homepage redirection configured behind the scenes?
While reviewing some documentation, I discovered a new rule table – Homepage Destination Rule [sys_homepage_destination_rule]. For instances with SOW installed, this table contains a single record that redirects all ITIL Non-Admin users to the SOW landing page upon successful login.
If you prefer agents not to be redirected to the SOW after login, ServiceNow documentation advises deactivating this rule. According to the access controls set on the sys_homepage_destination_rule table, only admins can edit the ‘Active’ and the ‘Order’ fields, while all other actions are restricted to the ‘maint’ role.
If the SOW Landing Page rule is functioning correctly, what about adding more redirection rules to the table? Could this be a low-code solution for managing landing page redirections? Indeed, it worked for our use case. We needed users with the ‘asset’ role to be redirected to the Asset Workspace upon successful login. In this article, we will outline the steps taken to achieve this redirection.
Configuration steps
Follow the steps listed below to add redirection rules for users logging into ServiceNow.
Create a User Criteria
- Navigate to the User Criteria [user_criteria] table.
- Either identify an existing criteria record that we want to make use of, or create a new one. For this example, we will be creating a new criteria for the ‘asset’ role.
Create a Homepage Redirection Rule
- Since the create access on the table sys_homepage_destination_rule is ‘maint’ only, there are a couple of ways that we can still create records.
- Modify the ACLs – technically possible, but not preferred
- Insert a record via a script – preferred approach to avoid ACL customisation
- For our Asset Workspace use case, we ran the below script in the background to create a new rule.
- Copyable version –
var grSHDR = new GlideRecord('sys_homepage_destination_rule');
grSHDR.initialize();
/* set a desired name for the rule */
grSHDR.setValue('name', 'Asset Workspace Redirection Rule');
/* order of execution needs be lower for higher precedence */
grSHDR.setValue('order', '10');
/* set the preferred application scope */
grSHDR.setValue('sys_scope', 'global');
/* set the landing page URL */
grSHDR.setValue('destination', 'now/assetworkspace/home');
/* set the sys_id of the user criteria record that was created earlier */
grSHDR.setValue('user_criteria', '78c20265c3530210662bbf0d0501313d');
grSHDR.insert();- Output – a record was inserted in the sys_homepage_destination_rule table.
- Clean the cache with ‘cache.do’.
Verify the configuration
If all the steps have been followed accurately, any non-admin user who matches the user criteria will be redirected to the Asset Workspace upon a successful login (works with impersonation too).
If your instance is several years old, the redirection rules might not function automatically. In such a scenario, create/set the following system properties in the global scope.
- glide.login.home = /now/nav/ui/home
- glide.next_experience.user_selected_landing_page_enabled = true
Next steps
Play around with various homepage destination rule records, test thoroughly and share among your peers.
Helpful