Use PDIs? Take our 5-minute survey to help shape the PDI roadmap.

Service Portal redirect for non-fulfillers

GChanner
Tera Guru

 OOTB by default users without a fulfiller role are redirected/dropped off at ..../now/nav/ui/home. We have modified the "SPEntryPage" script include to redirect non-fulfillers to the portal (/sp) upon login rather than .../now/nav/ui/home

 

Question: How does yours or other organization handle this:

1. Do you stick with or use the OOTB function .../now/nav/ui/home?

and if yes, how has the user experience been using the OOTB this approach?

2. Do you customize the "SPEntryPage" script include to redirect to ../SP?

 

The reason for my question is that I am trying to determine if we should rollback to the OOTB  "SPEntryPage" script so as to prevent this from happening in the future.

2 ACCEPTED SOLUTIONS

@GChanner 

Just following up to see whether my suggested solution worked for you.

If you're still facing any issues, I'd be happy to help further.

Regards,
Ankur
Certified Technical Architect  ||  10x ServiceNow MVP  ||  ServiceNow Community Leader

View solution in original post

ajmalmuhamm
Tera Contributor

Hey @GChanner ,

 

I would not recommend rolling back SPEntryPage just for the sake of staying OOB if the business requirement is that non-fulfiller users should land directly in the portal.

ServiceNow's current documentation specifically supports using SPEntryPage for conditional post-login redirection, and it also documents that glide.entry.loggedin.page_ess can be used to send users without platform roles directly to a portal.

The important consideration is that modifying the OOB SPEntryPage is a customization. ServiceNow notes that changes to the Script Include won't be upgraded automatically, so you need to account for those changes during upgrades.

My recommendation would be:

  • Keep the portal redirect if it provides the intended UX for non-fulfillers.
  • Keep the customization as small as possible, ideally changing only the role check in SPEntryPage.
  • Document the customization and compare it with the OOB version during every upgrade.
  • Test deep links carefully—for example, a non-fulfiller clicking directly on an incident or catalog item should still be taken to the appropriate portal page rather than simply being dropped at /sp.
  • If your requirement is simply "users without roles should always go to the portal," investigate glide.entry.loggedin.page_ess before maintaining custom Script Include logic. ServiceNow specifically provides this property for that scenario.

So, I wouldn't roll back purely because it is customized. If the customization is delivering a deliberate business requirement and is well documented/tested, it is a reasonable approach. The bigger concern is making sure the customization is minimal and revalidated after upgrades.

For reference, ServiceNow's current documentation on Single sign-on, logins, and URL redirects explains the SPEntryPage behavior and the supported configuration options. ServiceNow – Single sign-on, logins, and URL redirects

View solution in original post

4 REPLIES 4

HarishKumar6668
Tera Guru

Hi @GChanner ,

We have modified the redirection behaviour for users without a fulfiller role. We extended the SPEntryPage Script Include, overrode the getFirstPageURL method, and set the system property glide.entry.first.page.script based on the result of the script.

 

If you find this information useful, please mark it as helpful.

Regards,
Harish

Ankur Bawiskar
Tera Patron

@GChanner 

My thoughts and what we did in past

-> Keep the OOTB SPEntryPage unchanged where possible.

-> clone the OOTB script include and handle your logic there

-> update the properties to pick from your custom script include
- glide.entry.first.page.script = new CustomSPEntryPage().getFirstPageURL()

- glide.entry.page.script = new CustomSPEntryPage().getLoginURL()

💡 If my response helped, please mark it as correct and close the thread 🔒— this helps future readers find the solution faster! 🙏

Regards,
Ankur
Certified Technical Architect  ||  10x ServiceNow MVP  ||  ServiceNow Community Leader

@GChanner 

Just following up to see whether my suggested solution worked for you.

If you're still facing any issues, I'd be happy to help further.

Regards,
Ankur
Certified Technical Architect  ||  10x ServiceNow MVP  ||  ServiceNow Community Leader

ajmalmuhamm
Tera Contributor

Hey @GChanner ,

 

I would not recommend rolling back SPEntryPage just for the sake of staying OOB if the business requirement is that non-fulfiller users should land directly in the portal.

ServiceNow's current documentation specifically supports using SPEntryPage for conditional post-login redirection, and it also documents that glide.entry.loggedin.page_ess can be used to send users without platform roles directly to a portal.

The important consideration is that modifying the OOB SPEntryPage is a customization. ServiceNow notes that changes to the Script Include won't be upgraded automatically, so you need to account for those changes during upgrades.

My recommendation would be:

  • Keep the portal redirect if it provides the intended UX for non-fulfillers.
  • Keep the customization as small as possible, ideally changing only the role check in SPEntryPage.
  • Document the customization and compare it with the OOB version during every upgrade.
  • Test deep links carefully—for example, a non-fulfiller clicking directly on an incident or catalog item should still be taken to the appropriate portal page rather than simply being dropped at /sp.
  • If your requirement is simply "users without roles should always go to the portal," investigate glide.entry.loggedin.page_ess before maintaining custom Script Include logic. ServiceNow specifically provides this property for that scenario.

So, I wouldn't roll back purely because it is customized. If the customization is delivering a deliberate business requirement and is well documented/tested, it is a reasonable approach. The bigger concern is making sure the customization is minimal and revalidated after upgrades.

For reference, ServiceNow's current documentation on Single sign-on, logins, and URL redirects explains the SPEntryPage behavior and the supported configuration options. ServiceNow – Single sign-on, logins, and URL redirects