We are preparing for a full rollout and recently began exploring a full LDAP integration of all employees. The short story is that we allow LoginID changes when people marry, divorce, etc... Our Employee number is our unique value for personnel.
LDAP was creating new employee records for the new login ids which meant duplicate employee numbers. We changed LDAP to match on the employee number instead.
LDAP has a checkbox to overwrite the LoginID but I have been warned about losing "history" and "assignments" for people since most screens, lists, etc use the CurrentUserLoginID.
LoginID and PrimaryEmail are the two unique fields used to identify Employees. If you change the LoginID in the Employee record you risk losing all their 'history' (all old Incidents, email. notes, etc) as it will be treated as a new Employee. This is why it is not updated automatically.
There is a setting to copy over the LoginID also, its the 'Override Employee Login (Warning: Employee will no longer be able to view existing assigned records like incidents, tasks etc)' checkbox on the mapping page.
If the Employee is not the Owner of any Incidents, Tasks, Service Requests, etc then changing the LoginID is not that tricky. They have no history to lose.
If the Employee DOES own Incidents, Tasks, etc then those will need to be re-assigned to the new owner (new LoginID), which can be tricky but can be done.
Checking the checkbox to 'Override Employee Login...' will do every record with a new LoginID in the LDAP import - so be careful doing this, and be prepared to re-assign Incidents, etc to a new LoginID should one of them get changed. Their old Incidents will no longer show on Searches or grids as most of those Searches use CurrentLoginID() or similar function.
Looking for your creative solutions to deal with LoginID changes... Thanks - Mark.