Redirecting link from emails.

[kumar-adi]

I'm experiencing a weird behavior with the mail links of new snow as well as browser shortcut (see printscreen). when clicking on a link, it takes me to the itil frontpage. if i click on the same link again without closing the browser, i get a second tab with the correct page. as soon as i close the browser, it starts all over again. first click: itil frontpage, second click: correct page. I

s this behavior normal in ServiceNow or we can fix this ??

[kumar-adi]

@Ankur Bawiskar 
Hi , Yaa that's fine but what if I want this settings as it should directly redirects to the correct page . Is there any way or configuration to achieve this?

[Ankur Bawiskar]

@kumar-adi 

are you saying even if user is not logged in user, take them correct page and then ask them to login there instead of portal home page?

If yes then that's not going to happen

Example: if you are taking user to take survey page in SP portal and user is not logged in, they will see login page for SP and once they enter credentials they can see the actual page

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

[Ankur Bawiskar]

@kumar-adi 

Hope you are doing good.

Did my reply answer your question?

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

[kumar-adi]

Yup , Thanks for reminding for screenshots. Also , As per my understanding its first making the user logged in and then again clicking on the same link redirecting to the correct page . 

[MaxMixali]

ServiceNow – Mail Links Redirecting to ITIL Frontpage on First Click

Issue Description:
--------------------------------------------------
When clicking a ServiceNow email link (e.g., to an incident or record), the browser first opens the ITIL homepage instead of the intended record. On the second click (without closing the browser), it correctly navigates to the target page. However, closing the browser resets this behavior — first click always goes to the ITIL frontpage again.

--------------------------------------------------
Root Cause:
--------------------------------------------------
This behavior is not normal but typically occurs due to **session handling or login redirection issues**. The most common causes include:

1. **SSO (Single Sign-On) or authentication redirect sequence:**
- On first click, ServiceNow triggers the SSO authentication and opens the default landing page (often the ITIL homepage).
- The actual record link is lost during the redirect because the authentication flow doesn’t preserve the target URL after login.

2. **Browser session cookie issue:**
- Cookies (such as `glide_user_activity` or `glide_session_store`) are not yet initialized during the first session load, causing ServiceNow to redirect to the default homepage.

3. **Deep Link URL formatting:**
- If the email link uses a relative path (e.g., `/nav_to.do?uri=incident.do?...`) instead of a fully qualified link with instance URL, it may fail during first authentication redirect.

4. **SSO timeout or IdP configuration issue:**
- Some SSO implementations (Okta, Azure AD, ADFS, etc.) don’t maintain the relay state (the deep link reference) during the first login redirect. This results in landing on the default page instead of the target record.

--------------------------------------------------
Verification Steps:
--------------------------------------------------
1. Open the email link in an **incognito/private browser window** — observe if the issue persists.
2. Test using **local login (bypass SSO)** — append `?sysparm_no_redirect=true` to the URL and check behavior.
3. Check if the email links are **absolute URLs** (e.g., `https://yourinstance.service-now.com/incident.do?sys_id=...`).
4. Review **SSO relay state configuration** in your Identity Provider (IdP).
5. Confirm if the behavior occurs across all browsers and users (browser cache and cookies may contribute).

--------------------------------------------------
Resolution Options:
--------------------------------------------------

✅ **Option 1: Fix RelayState / Deep Link Preservation in SSO**
- Configure the Identity Provider (IdP) to pass and restore the relay state parameter.
Example: For **Azure AD or Okta**, enable *RelayState persistence* in the SAML app configuration.
- Ensure the ServiceNow instance is configured with the proper **Entity ID and Assertion Consumer Service (ACS) URL**.

✅ **Option 2: Modify Default Landing Page**
- Navigate to **System Properties → Homepage**.
- Update the default homepage for the ITIL role to redirect users back to `last visited` or a neutral page to minimize confusion.

✅ **Option 3: Update Email Template Links**
- Use **fully qualified links** in notifications to preserve the redirect target.
Example (correct):
```html
<a href="https://yourinstance.service-now.com/nav_to.do?uri=incident.do?sys_id=${sys_id}">View Incident</a>
```
Incorrect (relative):
```html
<a href="/nav_to.do?uri=incident.do?sys_id=${sys_id}">View Incident</a>
```

✅ **Option 4: Maintain Session Persistence**
- Enable “Keep Me Signed In” or ensure session cookies persist across browser restarts if permitted by your org policy.

✅ **Option 5: Test with OOB login module**
- Temporarily disable SSO or test with native login to confirm the redirect logic works as expected.

--------------------------------------------------
Best Practice Recommendation:
--------------------------------------------------
- Always use **absolute URLs** in email notifications.
- Verify **SSO relay state configuration** in your IdP.
- Avoid custom login redirects unless necessary.
- Educate users to remain signed in when possible to avoid re-login redirects.

--------------------------------------------------
Conclusion:
--------------------------------------------------
This behavior typically indicates a **login redirect issue** caused by SSO relay state loss or cookie initialization.
It’s not expected OOB ServiceNow behavior — correcting the **SSO configuration**, **email URL structure**, or **session handling** will resolve it.
Work with your **SSO administrator** to ensure deep link relay state persistence is enabled in your identity provider setup.