Name formatting in Workday

I am currently looking at Workday's name formatting. When a user logs to look at an employee's data or to enter a new employee they see a country-specific name format, like this one for the US:

Workday defines the name format for you by country. It is one of those 'it's SaaS you'll take what you're given' situations.

For my dear readers in India, the India name format is this:

• Prefix, Given Name(s), Middle Name, Family Name, Local Given Name(s), Local Middle Name, Local Family Name, Suffix

For our friends in China, you'll see this when you enter a Chinese employee:

• Title, Chinese Family Name, Chinese Given Name, Given Name - Western Script, Family Name - Western Script 

This structure looks great and you'll be consistent. No matter what company you're working at you'll always see the same fields per country.

Here's the name formatting challenges in Workday:

1. You cannot turn parts of a name on or off.

Some companies consider their payroll systems to be 'king,' especially outside of the US. If your payroll system only contains first and last name but not middle name, you'll need to add the middle name into the first name field instead.

When Workday does not let you hide the middle name field you'll be in a regular audit battle to get your self-service or HR users to put it into the first name field instead of the delivered middle name field.

Or you need to code around it, so that your interface to payroll takes the middle name field and concatenates it into the first name field.

In my perfect world the customer would be able to configure what fields they would like displayed per country.

2. Workday dropdown values are not delivered.

I had thought that one of the advantages of a standardized SaaS would be to deliver standard values such as the name prefixes like 'Mr.' and 'Mrs.' This isn't the case, they are defined locally in each tenant. In theory, you set these up during your initial implementation and never touch them again. It becomes interesting if you do an acquisition or merger of two different systems however...

For the United States company A has 'Mr' set up and so does Company B. Each company has had to set up these values on their own.

It becomes interesting because the references IDs are different.

Company A set them up consistently using the full country names:
Mr_United_States_of_America
Mrs_United_States_of_America

Company B used country codes instead, so they look like this:
MR_USA
MRS_USA

At one point they started to add a 'w2' and 'w3' which was probably 'wave 2' and 'wave 3', so that we had 'MR_CAN_w2'. In a few cases they missed to add any reference ID so the system generated one for them.

The end result is a patchwork mishmash of inconsistent coding for the reference IDs which are used by integrations.

Company A and B need to go through an exercise to decide which values and reference IDs will be used in the future state and integrations need to be reviewed and revised.

I just don't understand why Workday doesn't deliver some of this stuff right out of the box.

Names in Workday

We're starting to get into the data analysis phase here in Europe.  Something new I learned about Workday today--names are not configurable per country.  To put it another way:  if WD defines that country xyz has name format (first last) and country abc has name format (first middle last), then that is what you get.

Understanding WD is defining a global solution based on name requirements around the world, as they understand them.

Also sitting here looking at the analysis done by one of my analysts to compare our current PeopleSoft names data to the Workday global matrix (a helpful resource that lists out per country the various fields available for items such as names).

We have a mismatch in a number of countries.  :-(

So now, we'll need to look closer, per country, to figure out what to do with our current data.  A few options, of course:

• Delete the middle names from PS.  Don't store going forward.
• Concatenate into the first name field in WD.  Then, get smart coding that parses out the middle name part depending on the country/interface.  Deal with the fallout if Middle Names (located in the first name field) are pulled into a report by an analyst and distributed further.
• Put middle names into another solution such as a Custom Object.  Then build rules that 'if country is xyz, then concatenate this field with First Name when sending the data to downstream system 123.  Force the report analysts to reference it as well.

In a perfect world, WD would make this a configurable item for me, so that I could use checkboxes to select which name types apply to a country.  Just sayin'.

Once we start making the conversion decisions, I'll give you an update about how it all turned out...