How to handle workers who don’t use their actual names

We all know them.

They walk among us.

People who don’t use the names their parents gave them.

They’ve been causing HR people headaches for years. You can’t find them in alpha lists, the payroll department never know who you’re talking about and you risk public ridicule (not to mention GDPR complaints) if you accidentally call someone by their actual name.

But all joking aside, there are plenty of perfectly legitimate reasons why people might choose to go by a different name to the one on their birth certificate and bank account. They might prefer a shortened version of their first name, they might use their middle name (especially in those families where everyone has the same first name) or they might be in the process of changing the name on their birth certificate. I’ve ticked more than one of those boxes myself in my time. So we need to find a way to make this work – and fortunately, Talent has a few options up its sleeve to help us out.

When it comes to entering a new worker’s name, there are six significant fields:

  • First name
  • Middle name
  • Last name
  • Known as
  • Search name
  • Display as

There are a few other options in the mix as well, and once you know how to use the core 6 you can branch out among the others. If you operate in Spanish influenced countries for example, you’ll find ‘last name prefix’ is a useful option. For the purposes of this post though, I’ll focus on these six.

First, middle and last names should be obvious. You need to record here what the person’s legal name is. There are very few scenarios in which you wouldn’t want to do this, and those exceptions would need to be handled very carefully. Once you’ve put the accurate, proper values in these fields, we need to think about how to accommodate those awkward people (like me) who don’t use their legal name for common use.

First thing to know – when you enter a worker, Talent creates a ‘person’ record for them in something called the Global Address Book. You can google that later, but basically it’s a record of all the people entered into Talent, including current, past and future workers, people listed as emergency contacts, beneficiaries, or dependents, and trainers. In their GAB entry is a field called ‘Name’. The name field is a single text string, comprised of the constituent parts of the person’s name. You can control which parts are used to create that string, and in what order, using the ‘Display as’ field. When you first create a worker, that ‘Name’ string is populated using the default ‘Display as’ setting – which is FirstMiddleLast. This is why if you’ve created your workers properly, entering their legal names in full, you’ll start seeing middle names in lists of workers.

That’s not the end of the world, but there are a couple of potential problems:

  1. The GAB Name string is what’s shown to managers to identify their direct reports in self service, and some of your workers might not want to share their middle names with their boss
  2. When you’re searching for the worker in a list, searching for Firstname Lastname will give no results. I’ve seen this end up with duplication of entries, because an assumption is made that the worker doesn’t exist. You can get round this by training your users on how to use search more effectively, but it’s still something to consider.

So when you enter a worker’s name – take note of that ‘Display as’ field, and make sure it’s set to something which makes sense for this worker, so the ‘Name’ string in the GAB gets populated with something meaningful.

Right – so we get what that field does. What’s in it?

As standard, you get a range of options with combinations of first, last and middle names. Some of them put last name first, some of them put first name first. I don’t actually think there’s a right or a wrong approach to this. Some organisations are used to being able to easily get a list of workers, alpha sorted by last name. If that’s you, then choose your option here accordingly. Personally with search so flexible now I don’t see that it matters. And if you get it wrong, you can always change it later.

But – there are people out there (me included) who aren’t known by their legal first name. My birth certificate says ‘Thomas’, but the only person who ever calls me that is my mother, when I’m in trouble. And my boss, because he knows that and likes to wind me up. There’s obviously a field in the mix (‘Known as’) which can help us out here. But if we want to pull this value into that GAB Name string (which, remember, is visible in ESS) we need to add an option to the Display As list.

To do that you can use the old right click/view details trick on the field itself, or navigate through the menus to Organisation administration > Links > Global address book > Name sequences. Here you have the option to add the Known As field, as well as Last Name Prefix, into the mix. I won’t patronise you by telling you how to create a new name sequence option, it’s pretty self explanatory (even though it can render in a slightly odd way on certain resolutions). You can have up to four parts in any given sequence, with (pretty much) any separator you like.

Once you’ve created your name sequence option, you can go back into the worker and update the value held there. Hey presto – that name string in the GAB will update, and suddenly Tom, Sam, Alex, Jo, Matt – or whoever – doesn’t feel like they’re about to get told off every time they open self service.

It’s worth noting that this solution works just as well with people who use their middle name in place of their legal first name. Again there are a couple of ways you can handle it – you could put the middle name into ‘Known as’ and follow the rules above, or set up a name format which is MiddleName LastName. If I was a purist, I’d say I prefer the second option, only using the ‘Known as’ field when you need to add to the string a sequence of characters that you can’t find elsewhere in the name setup. But it’s really a case of organisational preference and what comes most naturally to your user group.

As an aside, if you (as most people do) quickly realise that FirstLast is a much better default option for the DisplayAs field than FirstMiddleLast – you can change this in the Global Address Book parameters (Organisation administration > Links > Global address book > Global address book parameters).

But wait… I’ve missed one. Search Name.

Search name, funnily enough, is a free text field. It can contain anything you want. When you first create a worker, it’s populated with the same value as the GAB Name string, but then it loses all association. If you hire a worker called ‘Christine Jones’, her GAB Name is populated as such, as is her ‘Search name’. If you then add a Known As value of ‘Chris’, and set display as to ‘KnownAs Last’ – her GAB Name string will update dynamically, but her Search Name won’t. And this is where it gets tricky, because in some places in Talent, it’s the GAB Name which gets surfaced, and in others, it’s the Search Name. Take People Hub as an example:


The top field there is showing the Search Name value – which was auto-populated when we entered Chris’ legal first name at the point of hire. We’ve subsequently gone in, added a Known As, and changed the Display As value. The GAB Name string has been updated – and that’s what’s showing in the bottom highlighted field.

In 6 years of working with this, I still haven’t quite worked out a best practice approach to the situation. You have to get the GAB Name bit right if you’re launching self service – because that’s the string which is visible to employees and managers.

For HR users though:

  • People Hub uses Search Name
  • Org hierarchy views use Search Name
  • Company Directory uses First Name and Last Name
  • The worker column in the positions list page uses GAB Name
  • The person lookup in user account settings shows both

At this point I talk customers through the options, and we decide which approach is best for them based on which bits of the product they’re using, and how willing they are to keep both values in sync.

When I’m feeling sensible I’ll go and log an Idea for this to suggest it gets reviewed, for most consistency.

2 thoughts on “How to handle workers who don’t use their actual names”

  1. Thanks for sharing this info Tom. In our implementation, we are using KnownAsSurname as name sequence as per the customer requirement. There is a data breach issue when we create a personal contact in ESS, if we are using the above name sequence. Have raised this bug to Microsoft and they are fixing that. Lets say when I create personal contact in ESS > entered only first name and clicked on OK, then system is picking some random personal contact of other employee and displaying it there. Since the default name sequence we had set is KnownAsSurname, system is unable to find both KnownAs (which is missing in personal contact screen) and Surname, system is unable to get the Name (which is a display field) and fetching some random detail.
    Yet, we need to be careful on these things.

    • Thanks for flagging this up Pavan, that’s a good catch. Personally, I never set the default name sequence to anything other than first last, although it’s a conversation I’ve had many times. I never understand why it needs to be a ‘one size fits all’ solution, I prefer to pick the name format which is appropriate on a per worker basis. Would you mind reporting back here if you hear any news from MS on the bug you’ve identified? Thank you!


Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.