Skip to main content

Hi everyone, this question is intended for those of you who have users who login with a username and password (non-SSO).

With the November 2020 release, there was a “security” enhancement that removed the ability to add a personalized link in the "User has been created (by administrator)" email to allow users to set a password for the first time. As a result, the new user activation flow is very complicated and confusing unlike any other technology I’ve used. Here’s the 6-step process:

  1. User is created.
  2. User receives "User has been created (by administrator)" email with a link to Reset password.
  3. User clicks link to go to the Reset password page.
  4. User enters their email address to get a password reset email.
  5. User receives password reset email and clicks the personalized link to reset password.
  6. User sets their first password.

To get around this, we've had to create manual processes in which we set the password for the user (and require them to reset upon first login) and send activation emails outside of Docebo via a mailbox and a mail merge in Word/Excel/Outlook. It's a lot of work, but the new user activation experience is so important for us, especially as we provide training to our customers.

It looks like there have been some ideas posted in the Ideas portal related to this, but until this is addressed, would you have any ideas or recommendations for how we could streamline the activation flow for non-SSO users?

Thanks in advance!

Something doesnt sound right here.

The message is editable….can you elaborate?

The "User has been created (by administrator)" notification is editable, but the user_password] tag doesn’t work as intended. Instead of the actual password in plain text or a personalized link for first password reset, users will receive a standard reset password link (the same thing could be done by just copying and pasting the forgot password link).

This means that users have to do a couple more steps than before (receive user created email, click on the reset link, insert mail/username, receive a second email with personalized link, click on the link for password selection).

At least this is what happens to us and I believe that’s mikevickers issue

Following, as I just last week stumbled onto this same workflow In my case.

Typical:

User receives password reset link in email, clicks it, and enters a new password (twice to avoid mistaken typos) and then is done.

Docebo:
User receives a password reset link (which is injected via the “password]” shortcode but is renamed in the email to ‘reset your password’) to reset the password. User clicks on it and it just brings them to the standard password reset form which asks for their email address only. They enter their email address and then the LMS emails them *another* link that they must click on to actually reset their password. 

We’re considering just removing the epassword] (reset your email) link and just directing the user to go to the LMS and click the Forgot your password? link. It would be really nice (and, typical) if we could just link to the forgot your password page...but alas no.

Something doesnt sound right here.

The message is editable….can you elaborate?

Thanks for the reply. I’m not sure what else to add here. The November 2020 “security enhancement” created a 6-step process for activating a non-SSO account, which is not ideal for new users. Docebo is the only tech platform I’m aware of that handles non-SSO users in this manner. Please let me know if I can help to clarify anything specific or if you have any ideas of how we can get around this. Thanks!

But dont you get a chance to control that workflow.

Am I wrong by saying - users do not need to do a password reset?

In advanced settings Under the Password Verticial Tab:

Password Policy in advanced settings, dont you get a chance to uncheck - “Force Users To Change Their Password At Their First Login” as an option by default upon user creation?

You get chances when you are loading via CSV as well to disrupt that flow

In Advanced Settings under the Users Tab -
You also dont have automatically calculate a password which should simplify the flow?

Wouldnt pairing those two allow for you to generate a pw, essentially pushing a known one to users with step #2, where they dont have to change their passord?

By the way? I am just implementing - so I super appreciate your insight….

But dont you get a chance to control that workflow.

Am I wrong by saying - users do not need to do a password reset?

In advanced settings Under the Password Verticial Tab:

Password Policy in advanced settings, dont you get a chance to uncheck - “Force Users To Change Their Password At Their First Login” as an option by default upon user creation?

You get chances when you are loading via CSV as well to disrupt that flow

In Advanced Settings under the Users Tab -
You also dont have automatically calculate a password which should simplify the flow?

Wouldnt pairing those two allow for you to generate a pw, essentially pushing a known one to users with step #2, where they dont have to change their passord?

By the way? I am just implementing - so I super appreciate your insight….

Hi there, thanks again for your response. I really appreciate it!


We have both of those checkboxes you mentioned unchecked.


Unfortunately, you can’t push a known password to users via the "User has been created (by administrator)" email as there’s no way to populate it in the activation email anymore. As a result of the November 2020 security enhancement, “the user_password] and the rpassword] shortcodes will no longer show the user password and will show the Reset Your Password link instead.” 

 

We have to work around this by setting a unique password for user via the user creation form or a CSV upload, and then sharing that in our own activation email outside of the system (sent individually or through a mail merge). While it’s a painful, manual process, we have taken on the brunt of the work so that our non-SSO users have a simple activation flow and positive experience from day one.

 

I’m hoping that someone has a workaround or that Docebo can help us solve this issue.

@dklinger notifications can no longer send passwords “in the clear” (IIRC this was a GDPR compliance requirement?). So there’s no way for users to know what the system-generated password for them is, unless manually emailed to them (which is bad practice). 

I see...and yes I can understand your concern much better now. Thank you for that level of detail.

Any news on this?  That first new user experience is so important to us and we have yet to figure out how to make it both pretty and easy.

Reply


Terms & ConditionsCookie settings