ServiceNow Login Redirects to Previously Visited Page: Is This Expected Behavior?

一江吴 · 4 weeks ago

I have implemented a flow using code that works as expected in most cases:

1，Access https://myInstance.service-now.com/csm (no login required initially).
2，An external user logs in.
3，After login, they are redirected to /csm (as intended).

However, when testing the following specific steps, the result differs from my expectation:

1，Access https://myInstance.service-now.com/now/nav/ui/home while not logged in.
2，Navigate to https://myInstance.service-now.com/csm without logging in first.
3，The external user logs in on the /csm page.
4，Instead of redirecting to /csm, they are redirected to /now/nav/ui/home (the page visited in step 1 before logging in).

I suspect this behavior is normal in ServiceNow, similar to how users are redirected back to the page they were viewing before a session timeout when they log in again.

Is this indeed the expected behavior of ServiceNow's login redirect mechanism? I’d appreciate any insights or explanations. Thank you!

JackieZhang · 4 weeks ago

you need to change the script include SPEntryPage to align your requirement.

一江吴 · 4 weeks ago

Hi there,

Thank you very much for your earlier suggestion to modify the SPEntryPage Script Include to align with our requirements. I appreciate your input!

Following your guidance, I implemented a solution using inheritance instead of directly modifying the out-of-the-box SPEntryPage (since direct edits to core system Script Includes are high-risk and not recommended). Here’s how I set it up:

Created a custom Script Include CustomSPEntryPage that extends SPEntryPage.
Overrode the getFirstPageURL method in CustomSPEntryPage to define our desired post-login redirect logic.
Configured the system property glide.entry.first.page.script with the value: new global.CustomSPEntryPage().getFirstPageURL() to enforce the custom logic.

Current Behavior (Working Scenario):

The custom logic works as expected in this flow:

Access https://myInstance.service-now.com/csm (Service Portal, no login required initially).
External user logs in via the Service Portal login.
Post-login, the user is correctly redirected to /csm (as defined in CustomSPEntryPage.getFirstPageURL).
In this scenario, CustomSPEntryPage is invoked, and our logs confirm it runs as intended.

Issue (Non-Working Scenario):

However, the custom logic fails to trigger in this specific flow:

Access https://myInstance.service-now.com/now/nav/ui/home (traditional UI) while unauthenticated (triggers a login prompt).
Switch to https://myInstance.service-now.com/csm (Service Portal) without logging in first.
External user logs in via the Service Portal login.
Post-login, the user is redirected to /now/nav/ui/home (traditional UI) instead of /csm.
In this case, our logs confirm that CustomSPEntryPage is not invoked at all, and the redirect follows the traditional UI’s default behavior.

It seems the custom CustomSPEntryPage logic is only triggered when the login flow starts directly from the Service Portal. When the user first interacts with the traditional UI (even if they later switch to the Service Portal to log in), the custom logic is bypassed, and the redirect defaults to the traditional UI’s target.

Do you have any insights into why CustomSPEntryPage isn’t being called in this second scenario? Could there be additional system properties, session properties, or configuration steps I’m missing to ensure the custom logic applies universally across both Service Portal and traditional UI login flows?

Thank you again for your help!

Best regards,

JackieZhang · 3 weeks ago

you need to change those two sys_properites:

* glide.entry.page.script new SPEntryPage().getLoginURL();

* glide.entry.first.page.script new SPEntryPage().getFirstPageURL();

Actually I suggested to modify it in original OOTB SPEntryPage() script include.

一江吴 · 3 weeks ago

Hello,

I’m facing a redirect issue with traditional UI login flows that bypass the SPEntryPage logic, and I’d appreciate your insights. Here’s the scenario:

Problem Description:

When an unauthenticated user first accesses a protected traditional UI page (e.g., /now/nav/ui/home), the system redirects them to log in. After logging in (whether internal or external users), they are forced to redirect back to the initially accessed URL (/now/nav/ui/home), even if they switched to another page (e.g., /csm) before logging in.

Key Observations:

The redirect behavior persists regardless of user type (internal/external).
The flow seems driven by a session property:
1. Unauthenticated user visits /now/nav/ui/home (requires login).
2. System redirects through /session_timeout.do and eventually to the login page (/navpage.do).
3. After login, the user is redirected back to /now/nav/ui/home (the initial URL).
However, if the user logs out and re-logs in directly (without first accessing a protected page), they redirect correctly to the desired URL (/now/cwf/agent/home).

What I’ve Tried:

Modified the glide.entry.page.script and glide.entry.first.page.script system properties to use SPEntryPage.
Directly updated the OOTB SPEntryPage Script Include to customize redirect logic.
Neither change affected the behavior, as the traditional UI flow doesn’t seem to invoke SPEntryPage in this scenario.

Questions:

Which script or component controls the traditional UI’s login redirect logic after an unauthenticated user first accesses a protected page? (It seems tied to a nav_to session property, but I need clarity on the core handler.)
How can I override or clear the nav_to property during login to force redirect to a specific URL (e.g., /now/cwf/agent/home) for all users, regardless of their initial unauthenticated page access?

Any guidance on modifying the underlying redirect logic for traditional UI would be greatly appreciated!

Thank you again for your help!

Best regards,