Interpret Merging Employees

For those who cannot understand how easily a duplicate employee could be added to the system, imagine this scenario.  A company has a main Administrator who works on TRACCESS on a regular basis.  They also have a secondary person who fills in while the primary is away.  For most of the employees in the system, their employee IDs have been entered as [first initial][last name].  However, the secondary, who is not as familiar with the naming convention adds an employee to the system, following their email naming convention, which is [first name].[last name].  Instantly, one person could have been entered into the system twice.

An even more relevant example that many companies who have used the previous versions of TRACCESS can relate to is the creation of two profiles for those employees who held a TRACCESS Administrator function.  In this case, if the Employee logged in as Jane.Smith, they were acting as a Learner.  If the employee logged in as Jane.Smith.admin, they were completing Administrator/ Supervisor functions.  Since the roles have been more clearly defined and separated in TRACCESS CI, you may wish to merge Jane.Smith (learner) with Jane.Smith.admin.

Depending on who updates their completions, this person may have certain tasks marked as complete on one profile, and other tasks marked as complete on the other profile.  Short of assigning this person to an Organization Unit that was assigned all processes, and reporting on all of their statuses except incomplete, then creating an import file, there was no way to view a person's records at the same time.  

The merge employees function attempts to pull as much relevant data on the employee as possible into a single profile, thus eliminating the second duplicate profile.  This also has the positive side effect of freeing up license space, since licenses are calculated based on the number of employee profiles in the system.

The following is a list of things that are merged into a single employee profile.

 

In most cases, you will not necessarily want to know what IS merged, but what IS NOT.  This can be summarized by looking at the dialog that is used for the merge itself.  Anything that is a direct employee property is not merged.

Although the "fish" do not appear on screen, and may seem uncharacteristically out of place in software documentation, they have been placed there for a reason.  The merge functions (both Employee and Task) are some of the only functionality in the software that once completed, cannot be undone.  It is imperative that the correct object be chosen on the correct side.  The one on the right is the persistent object, the one that stays after the merge.  The one on the left is the transient object, the one that is deleted after the merge.  In other words, the big fish always wins.

The merge employee dialog could also be used as a Compare Employee Property dialog (before actually doing the merge procedure).  All of the direct employee properties are listed.  Of these properties, there are only three properties that are read-only, and cannot be reset to something else after the merge.  These are:  Account Created On, Last Successful Login, and Password Changed Date.  For the most part, the Password Changed Date is not something that companies are overly interested in.  The Last Successful Login date will change as soon as this employee logs in to the system again.  This leaves the Account Created On date to concentrate on.  Keep in mind that the Account Created On date is the date that the person was entered into the system, this date cannot be modified or set by the TRACCESS Administrator, and this date does not always correspond with the actual date of hire of the person.  However, you may wish to determine which employee is persistent based on the oldest Account Created On date - simply as a rule of thumb.

Once you have determined which Employee profile will be the persistent one, click Cancel through the Merge Employees dialog, and return to the Organization Manager.  At this point, you will hopefully have a list of all of the properties of the persistent object (big fish).  Select the persistent employee, and modify its properties accordingly.  Next, select the transient employee (little fish), and add the words (to be deleted) next to their first name.  This will assist in selecting the correct employee for the merge process.

Please note, other than the three read only fields mentioned above, all properties can also be modified after the merge.

What is lost

The only other thing that is lost after merging an employee is if someone has a bookmark set to the transient employee (within the Organization Manager).  TRACCESS CI will attempt to resolve the bookmark, and in doing so, the following dialog will be displayed.