When a person's name changes in our HR system, the new name and login id are imported into PPM. Any demand tickets in PPM still point to the old user id, and when the person logs in with the new id, PPM doesn't seem to have a way to connect the old id's activity with the new one. This also applies to dashboard set up, portlet filters, etc.
What are the techniques that others are using to manage this issue?
I would recommend updating the current userid rather than creating a new one. If you create a new userid, the only way to keep a history of that user would be to globally replace any reference to the old user id with the new one.
1. As you mentioned that 'When a person's name changes in our HR system, the new name and login id are imported into PPM.', so the login id is also coming from HR, that means, you can control this at HR system. Ask HR not to modify the login id or the person whose name has changed and trigger a notification from the HR system when a name is changed. Once you (PPM Admin) receives the notification, then PPM Admin can manually change the login id in the Workbench for that user. After that, ask HR to change the login id, the similar one, in the HR systems. That way both systems got synched for that user permanently. I know this is a manual process, but it will help resolve the issue.
2. Create the unique user_id parameter in the HR system, which should match with the PPM user_id parameter of the knta_users. This will be a one time activity for all the existing users. For every new user in HR system, you will still need to pass the new user's user_id to HR from PPM so they can update their database. This you can use, again, if you are not using the OOTB PPM Run User Import Report. Again not an elegant option.
But the reason is there's no direct way or no way for PPM to know if the user's name has changed. It only checks that if the login id is matching in HR and PPM then it wlil update record otherwise it will create a new record.
So your only bet is that HR should not change the user's login id. This happens in so many applications, that when a person's name is changed (e.g. a girl gets married and last name changes), the login id remains same, the previous one, until all the application admins manually change the ids in each application individually, manually and around the same time. As such there's no way for each application to know by itself or create a link between old and new id. This definitely does not exist in PPM. Till then, do not create a new user in PPM, just manually change the person's name and login id in PPM. Ask HR to provide that to you everytime a person's name is changed. Hope that helped a bit.
You need to change the login id at only one place and only once in PPM. You don't need to change is globally everywhere in PPM. Just modify it in the Workbench user screen. That's it and you are all set. Rest PPM will take care of it internally by using the user_id of the knta_users table.
Also, once you update the login id in PPM all the synchronization with HR systems will automatically happen correctly for such user. All is set. Nothing more to do.
Thanks for the excellent advice. I had noticed that there was a PPM-generated number assigned to the individual username records in the database, so I surmised that a pre-emptive change to PPM prior to LDAP import would produce the desired result in the way that you have outlined. I just needed to hear it from someone who had some experience with it. If anyone else has better or additional suggestions to enhance the integrity and efficiency of this procedure (such as the use of the update log file), please post.
One other thing to consider. If your HR has an Employee ID that does not change (almost everyone does) then you can add that as user data to your PPM users. This will allow you to tell if you are importing a "new" user (ie. changed name, login) that already exists and really should be an update.
You can also use the DEST_USERNAME column of the KNTA_USERS_INT table, to overwrite the existing user to avoid getting new created due to the name change. But in that case also, you have to have some identifier from the HR systems saying that this user's name has been changed. If you do not have any identifier whatsoever from HR systems then how will the PPM also know that's its an existing user? So HR system has to send some thing that says that the original name of the user was this and new is that. Or send the user id or original username, something for you to track it and avoid getting new created. But in case of using the DEST_USERNAME column also, you need track it in the KNTA_USERS_INT table and test it out completely, to check if this may help you.
So, Darshan, if I can populate the DEST_USERNAME with the old username (I call it logon id), will PPM automatically look for that username in the PPM table and do a simple substituion new username for old username without creating a new username record? That sounds ideal! Requests that were attached to the old username would then still be tied to the same username table record, but the record would have a new username.
If it is not an automatic substitution as described above, then where could I inject some logic into the LDAP-to-PPM update process to do this substitution?
You guys are the best! I didn't get nearly as much good quick responses when I used the Mercury discussion forum.
Erik, I had hoped to use employee id until I ran into the issue of outside consultants working under contract who later become employees. There is no carryover person ID from the contractor status to the employee status. When they become employees, they get a new login id (USERNAME) and a new employee number. Ordinarily, the name would stay the same, but, as we know, names can change too.