Hi @Winnie Cairney ,
I follow the same process you are doing when there is a name change and the employee ends up with two accounts. I merge the accounts, then deactivate the old one.
We also perform a regular refresh of our employee data from our HR System, but I also have a scheduled report in Docebo that dumps all the employee accounts and a termination list from HR. In the workflow integration application we use, I use the HR number to compare the lists to identify new hires, terminated employees, and people on a leave of absence (LOA). The critical assumption is that the HR employee number is the one source of truth and is correct. This creates three imports:
- Add new hires and refresh of all existing employee accounts. This list would replace the name and/or email address in the case where the employee had a name change.
- Deactivate and move terminated employees to an “Inactivated” branch in case they are ever rehired.
- Temporarily inactivates the account for anyone who is on LOA per our HR policy. This includes employees on garden leaves prior to termination.
As a check, I also send an alert email to the Super Admins when the name or email address changes for an existing employee.
This works smoothly most situations, although converting a contingent worker/contractor to employee sometimes causes problems because HR issues a new HR number when the person becomes an employee. For those cases, I compare email addresses and the termination date of the contingent worker and new hire date of the employee for possible overlap.
Sounds like you’re not using email address for the username? We force the username to be the user’s email address and use that as the primary ‘key’ for employee record updates.
Each day we run an import (via automation rule) of a file exported from our HR system that checks if an existing user exists with that email address and, if not, creates a new one. There is also a rule to update profile fields and additional fields (e.g., last name) if that has changed.
@mark We do use the email address for the username and for SSO. But we found we could not depend on the email address as an identifier between the HRIS system and our Active Directory. A common problem is that the email addresses don’t match in the two systems when a person is first hired. HR enters the email address as specified in the new hire form. IT enters it based on what the hiring manager requests, which may not be the same as what they entered on the new hire form. (I know, you’d think we’d have this sorted out!) Plus you have the name change issue raised by @Winnie Cairney
Otherwise I think our processes are very similar.
We use the same process that you describe. I periodically pull a report and sort out those with duplicate ID numbers, merge, and delete the old. At least that way we preserve the training history.
