This is part three of my regular blog posts describing the building of our new web app product, HR Partner. Previous posts are available here and here.
In part one, I explained about the sign on methodology used - more specifically, how we would separate the user authentication system from the company databases. This was to facilitate one user being able to work across multiple companies easily.
This workflow also meant that is user Bob wanted to work with company Acme Industries, then Bob would have to request an invitation to join Acme Industries as a user. To do this, Bob simply clicks a link on the login screen and fills out his name and email address.
This information is then sent to the Acme Industries company admin user. They can then log in to HR Partner and in 2 clicks, approve Bob's application to join (or ignore it).
In our early Alpha testing, whenever the company admin approved a user's request, the requesting user (Bob in this case) would automatically have an account created for him, and be sent back a generic congratulatory email telling them that they could now log into the system and begin working with Acme Industries.
But wait - we have an edge case here that needs to be looked at more closely.
We have to consider whether Bob is a brand new user to the HR Partner ecosystem, or whether he has been around for a while and already has an active logon account.
If he already has an account, then he does not need to do anything more than to click on the custom company HR Partner URL to log in immediately.
If he is a NEW user, then his account would have been created automatically when he was approved, and now he has to create his password before he can log in.
TWO distinct paths of action, depending on their initial status. However, our initial version of the invitation process had only ONE generic email back to the invitee, asking him or her to either login or go through the password reset process.
Actually, to be honest, the initial version was clunkier than that. We actually sent back the congratulatory email, and added a proviso that if they were a new user, they were to expect a SECOND email shortly with the password reset instructions, upon which we would generate and send them a password reset email (the same password resent email as if the user had asked for one on the site).
I thought that it was ridiculous - getting one, sometimes two emails back from us depending on their status. I resolved to make this easier by only sending back ONE email to the user, and changing the content according to their initial status.
So now, the user gets back a nice congratulatory email, and within the email, they are EITHER shown a link to the company sign up page, OR they are given a link to the password reset page (our app now generates the password reset token before sending then the email, if they are a new user).
User already has an account with HR Partner and was approved to join a company.
User is new and has had their account auto created.
The end result is much less email clutter, and (hopefully) less confusion for the end user as part of his or her onboarding process.
NB: Upon further consideration, we are now working on the change password screen a little more too. We want to customise this screen a little more so that when the app detects that it is a new user changing their password for the first time, that it shows up a little welcome message in there too - just to make the screen a little more friendly than the usual stark password reset form.
Normal password reset screen.
Password setup screen for new users.
Both the above screen are actually exactly the same - it is just the wording that has been changed depending on the context - whether they are a brand new user, or an existing user wanting a reset.