- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-01-2020 05:34 AM
Hi
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.