Expand my Community achievements bar.

Join us for our Coffee Break Sweepstakes on July 16th! Come ask your questions or share your use cases on Creative Briefs for a chance to win a piece of Workfront swag!

Proof login problems

Avatar

Level 10
Hi Wondering if others have this problem and how you solved for it. We use SSO for logins. We also share Proofs with people who don't have a login( for review+approval). This all works fine until someone shares a Proof from someplace NOT within ProofHQ, ie from Workfront or from the notification itself where there is a big "share this with someone" link. When a proof is shared via NOT in ProofHQ, the user is directed to login, and it's not the SSO login. I understand the rationale: when they comment, ProofHQ knows how to record who made the comment. I don't understand why it doesn't go to the SSO login, and can't (according to WF Support). However, when someone is directed to that login, there is no way to request to get a username, and when someone naturally tries to use their SSO login, an error comes up. In addition, that person now has that link cached and they can NEVER get back into that proof until they clear their cache. The amount of hours of support I've had to figure this all out has been mind-boggling. There is no way to remove those "share" links in Workfront or in the proof notification so that people will stop using them. I'm training them not to use them, but still, they are very tempted to take the shortcut and share from those places. We have the mantra "Share Share" which means go to the Proof and Share/Share it from there. It's a song we sing while making a "W" sign with our hands. Yes we do. The suggestion from WF Support is to have a 2nd login that isn't related to the SSO but 1.I'm not confident you can even do that, and 2.how confusing is that for our users. Ideas about this? Feedback? Jill Ackerman
Topics

Topics help categorize Community content and increase your ability to discover relevant content.

1 Reply

Avatar

Level 9
I'm mostly commenting to follow along, but I've had some experience with the "Second login" thing. I'm pretty sure this will work- when you set up a user with SSO, an initial password isn't set up, so you need to uncheck "only allow SAML 2.0 authentication", reset their password (that will be the other login), and save. Then go back in and re-check "only allow SAML 2.0 authentication". I did this for a few users to ensure they have access to the preview sandbox and myself as an admin so I can get in should we have SSO issues. The upshot of this is that as an admin you're going to run into the same issues SSO promises to avoid. Its unwieldy and something I hope gets solved for soon. Anthony Pernice