Saura Sambit
Tera Expert

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.

 
sow_landing_redirection_rule.png
 

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

  1. Navigate to the User Criteria [user_criteria] table.
  2. 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.

 

asset_role_user_criteria.png

 

 

Create a Homepage Redirection Rule

       3. 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

      4. For our Asset Workspace use case, we ran the below script in the background to create a new rule.

 
insert_script_rule.png

 

  • 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.
 
asset_workspace_landing_rule.png

       

       5. 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).

 
asset_workspace_landing.png

 

Next steps

Play around with various homepage destination rule records, test thoroughly and share among your peers.

Comments
Mr Anderson
Tera Expert

This is awesome, I was playing around with this in my PDI to see about getting users with no roles redirected to the Employee Center and while it technically works, it goes to ESC within the navigation frame.  Is there a way to do this outside the frame, as if I was going to the address bar and typing in /esc?  I'm sure I could hard-code the value, but that would really work for only 1 instance.

Saura Sambit
Tera Expert

@Mr Anderson 

 

Right, this only works for landing pages within the main frame. For redirecting to portals upon login you need to write logic in a script include as outlined in KB0746730.

Chris D
Kilo Sage
Kilo Sage

Thanks for sharing. A few months later, no issues still, right?

This Homepage Destination Rule setup is one of the strangest things I've seen in ServiceNow. It's an incredibly useful functionality but they manage it with a maint-locked table... with one record...

This many-to-many design - using a table instead of a property - is clearly intended for (future) expansion and seemingly intended for easy configuration, but it's baffling why it's locked down right now (Washington DC Patch 8 here). Extra baffling since it seems to work as we'd expect.

 

We want to rollout SOW to one group initially so I understand I can technically just alter the ootb "ITIL non-admin" User Criteria as a workaround since the one Homepage Destination Rule points to it, but I don't know everything else that User Criteria is used for and I'd rather just deactivate that Rule and have my own Rule.

Update: just realized that this is actually what ServiceNow explicitly says to do: Redirect agents of a specific group to Service Operations Workspace (servicenow.com) - but of course it doesn't address your original use case to redirect other users to other workspaces.

Version history
Last update:
‎07-10-2024 09:30 PM
Updated by:
Contributors