This request is based on my experience/frustration over the past couple of weeks and it’s possible I’ve missed something that would address it. If so, please let me know.
Currently there are two distinct and incompatible ways to get to a solution article via a url:
If the end user has their portal set as “classic” the following link format works:
https://instance.freshworks.com/support/solutions/articles/articleID
If the end user has their portal set as “ask Freddy” the following link format works
https://instance.freshservice.com/home#solutions/articleID
If the user is setup for the “other” portal style, the link doesn’t work.
Almost more importantly the service doesn’t seem to contain a ‘handler’ if the user clicking on the link isn’t signed in to the portal when they click on the link. They are most likely to get a dead end kind of page rendering that doesn’t make it obvious that they need to sign in. Then if they do sign in, they are not redirected to the original target page, they just land on the portal page.
A better experience would be: a single url format that works regardless of the end user’s portal preference and a handler that identifies the need to sign in, handles the sign in process and then directs the end user to the original requested page.
Why this is a problem for us. Our user base is accustomed first and foremost to email based support and communication. We want to educate them about the availability of the portal by including links to solution articles the in communications we send out, but we can’t reliably do this in the current format, because we end up fielding support requests on how to get to the support article.
We are configured for SSO, so it’s not a matter of them needing to setup a user account on the platform.
