How to handle a User and HR Profile created during on boarding when the user later is created in the AD?

[palmen]

When requesting a new hire in the portal you have to fill in name and email for the user.
Since the user hasn't started yet, and this is what triggers the on boarding, the user doesn't exist in AD yet.

When submitting the request a new user and hr profile is created for the person with roles so they can access the onboarding tasks they receive.

The question is, how do we handle this user once the new hire has been created in the AD?
When the user is created in AD it will be imported as a new user to the user table.
Is there some way to set this up so it actually update the already created user? Or is the best practice to create a new user with the same but with the company email instead?

If we in some way update the existing user, the email will also be updated, which might be an issue since the new hire hasn't got access to the company email yet. 

How do you handle this part in the onboarding process?

[Christian Prob2]

Hi @palmen ,

It sounds like you are not using ServiceNow to actually create the AD account (in that case you can obviously link them up in one go, and even if the below still 'applies').

I have worked in environments where we had the following setting:

AD account access to ServiceNow via SSO - so once day 1 comes the new hire becomes an employee and we switch over the ServiceNow user record to an SSO enabled synced AD user record. So we keep the existing sys_user record and just 'reconfigure' it.

For that to work you need to have a unique identifier that allows for automated matching of the AD record (= 'what' gets synced / imported from AD) and the existing ServiceNow record. Either you add something from ServiceNow to AD, for example the Onboarding case Number, or you need to add something to the Service case or user that come from AD, like the new corporate email address, employee ID... something unique.

Then - I believe - some scheduled job quieries the 'new' records that come from AD and tries to match them up. You can use another scheduled job to the switchover nightly.

Other considerations:

1) You may create the AD account ahead of time, but really only want to do the switch over the night before the start day, so you don't lock out the new hire for too long and possibly prevent them from accessing document or completing onboarding tasks. Not sure if you are using Lifecycvle events but that lets you 'schedule' that nicely and automatically.

2) Consider sending the new hire an email to the private email just before the switch over so they know what's going to happen and that they will get their new corporate login and password on day one from their manager (or whoever)

3) Following 2 - also send an email right after the switch over so they know where to can find their onboarding tasks (and documents) in the corporate environment.

In the scenario above we ended up with two different portals, one for external that is the 'normal credential/password' login and one internal that is SSO enabled.

Hope that helps,

Christian

Please mark helpful or correct if you deem it so. Thank you.

[palmen]

Thanks for your input.

I was just checking how it works out of box in a PDI. The user and hr profile was created when I created a new on boarding.

Seems like this process you describe could work, just need to check how much configuration is needed for it to actually work since the current integrations might need to be updated with the new logic.

I was hoping there was some "out of box" solutions that took care of this.
We've previously build on-boarding on the platform before it existed in ServiceNow. At that time we created temporary users, once they were hired and started working they got a new user record from the AD and the old temporary one was inactivated.

[Christian Prob2]

I guess it depends on how much you need to retain from the onboarding case(s) to be accessible for the user after day 1.

Just thinking out loud, maybe you can also just switch the user of the onboarding case, then the AD user should have access to the case and documents after the switch. Just need to check/find out what happens with subcases and related tasks.
hmm, and you would also have to switch over the HR profile and job somehow...

[palmen]

Yeah, there are a lot of things to consider here for sure. My assumption is that most companies would face the same issues, so maybe there was something "smart" already implemented for how to handle this.

All input here is highly appreciated.