Deep link URLs

[ablakey]

Hi,
We are looking to generate email links that take users direct to tickets and applications via a CMS interface.. We've not been able to find a URL format that works...

i.e.
https://myinstance.service-now.com/incident.do?sys_id=6dd430ff3067d4005fe39dea903fa58e
works fine
https://myinstance.service-now.com/CMSPAGE/incident.do?sys_id=6dd430ff3067d4005fe39dea903fa58e
doesn't work..

our CMS page is configured as a self-service interface
Can anyone advise if there is an alternative URL format that works, or if we're missing something here?

[ablakey]

Hi Vaughn,
Many thanks for the suggestion, I tried structuring the URL as you suggest, and found it takes you straight to the ticket, but not via the CRM interface..
Regarding your question about SSO, yes we think the single sign-on is working OK.

[tyler_jones]

You guys are all very close. First of all, we want to be concerned that the SSO is being triggered. Is your CMS site public or private (under Content Management -> Sites -> the site in question, do you have a login page filled in? If so, then it is private)?

I also want you to know that you are not alone. There are known issues about these links logging you in, and then not redirecting.

The nav_to scheme is close, but it may trim out the CMS. That is because nav_to is a public page, and will not redirect you to your SSO. Incident.do will redirect you to SSO, but it will redirect you back to Incident.do, outside of the CMS. The fix is to use a redirect page that is private. Go to UI pages, click new, and make a page named 'redirector' with the following XML code:

<?xml version="1.0" encoding="utf-8"?>
<j:jelly trim="true" xmlns:j="jelly:core" xmlns:g="glide" xmlns:j2="null" xmlns:g2="null">
<script>
Window.location.href = "${sysparm_uri}";
</script>
</j:jelly>

With this page, you can redirect your CMS links through like http://.service-now.com/redirector.do?sysparm_uri=/ess/incident.do...

Since this new page is not public (by default, that is), it should redirect you to SSO and work when you authenticate successfully. Let me know if you have any questions!

[john_andersen]

I am not too familiar with your situation, but if you are using SAML & CMS/ESS, you will need to format your links similar to what is described in this comment linked here:
http://www.john-james-andersen.com/blog/service-now/supporting-kerberos-authentication-with-adfs-in-servicenow.html/comment-page-1#comment-1252

Let me know if this helps or not.

[Vaughn Romero]

You may also want to verify that CMS is honoring SSO.

http://wiki.service-now.com/index.php?title=Content_Management_Security#Why_does_the_CMS_Site_Bypass_Single_Sign-On_.28SSO.29.3F

[ablakey]

Sorry for my late response to this, and many thanks everyone for your advice.
I've been really wrapped up with final issues and getting close to rollout!

Eventually we've decided to go live without deep links in customer (ie self-service) emails, but the progress we've made is as follows..

1 Single sign-on and CMS - I don't believe single sign-on (digest redirect) works properly for CMS. Whatever we do the re-direct comes back to the non-cms homepage (ie start at https://myinstance.service-now.com/CMSPAGE/ and it takes you to https://myinstance.service-now.com/ No deep links work using CMS because of this fundamental issue.

2 We were able to partially get around this as follows
•Construct a "pre-digested" link to the CMS page (https://myinstance.service-now.com/CMSPAGE&SM_USER=#######&DE_USER=####### etc etc
•"Spoof" the CMS application - ovwerwrite the login page with the home page
Authentication works (after a fashion) because it no longer has to use the redirect.
We could also construct pre-authenticated deep links to pages that do not open in a frame (i.e wouldn't matter if it was CMS or not) - the kind of format that works is..
https://myinstance.service-now.com/incident.do?sys_id=#######&SM_USER=#####& DE_USER=#######
NB using nav_to.do does work with Digest Single Sign-on but always opens records in the default frame (ie can't use the CMS frame)

Having got this far we concluded the changes required to our digest sign-on server and the "Spoof" to CMS were too risky to implement in the time-frame we had.
If anyone has any ideas about something we might have missed, we are likely to want to re-visit this post-implementation.