Monthly Archives: February 2010

When the Employee First Name isn’t the Preferred Name

Posted on by
Reply

There’s a good chance many of you have run into this situation:  You have an employee you know as John Smith, but you can’t find John Smith in your employee dictionary.  There are other Smiths but no John.  You import the employee data from the HR system on a regular basis and John has been around for years.  But you scour the dictionary and find no John Smith.  Then you find out the guy you’ve all known as John is actually named Tiberius, but for some reason he doesn’t want to go by Tiberius.  In fact, he hates it.  Of course if you change the first name field in the employee dictionary record it will be overwritten the next time you import. 

I addressed this issue for a client by creating a custom field for a preferred name.  Next I modified the appropriate reports to check on the status of the preferred name field and if it was populated, use the preferred name instead of the first name. 

 

A common formula for names in a firstname-lastname format looks something like:

 

            {Employee.firstName} & ‘ ‘ & {Employee.lastName}

 

After adding the custom field U_PREFERREDNAME to the employee dictionary record, we can modify the formula to look like this:

 

If IsNull({Employee.U_PREFERREDNAME})

    then {Employee.firstName} & ‘ ‘ & {Employee.lastName}

        else {Employee.U_PREFERREDNAME} & ‘ ‘ & {Employee.lastName}

 

The preferred name field is populated manually.  Since that field isn’t mapped to the employee import it won’t be touched by it.  If the preferred name is left blank the formula will send Employee.firstName and Employee.lastName to the output.  If there is a value in the preferred name field then the output will consist of Employee.U_PREFERREDNAME and Employee.lastName. 

 

A pretty simple but effective fix.  Tiberius …er I mean John… is happy now.