Workday IDs and codes

In our current PeopleSoft world, we have processes and controls around codes, how we set up codes (we don't use smart coding, but instead next sequential), and interfaces tend to use the same logic to select certain populations, so it becomes a copy/paste exercise for new interfaces.

Workday provides a lot more on the coding front, so a few thoughts here.

Some foundational data operates with these options:

1. Workday ID

 

When you set up a new value, let's say you're setting up a new value of 'New York City' in the Location table, Workday generates an ID for that automatically in the background when you save the value.  It looks something like this, length 32:

z13a7c16a03333c4a44bb09afbdf72q73

 

The average user does not see this value, but may view it (if granted security) to 'View Integration IDs'.  Some other key points I've picked up on this one:

• It's a globally unique code across all customers
• It's also unique across instances (so your Location will have different Workday IDs in your production vs. sandbox tenants)

2. Reference ID

 

This one is a customizable value, or you can let WD set it for you.  In this case we'd have:

Location_ID = New_York_City_site if we allowed it to default.  But you could override it to a value that makes sense to your company.  In our case, we have a code structure for locations that is set up by the facilities group and used universally at our company.  So our Reference ID is overriden when setting up a location, to be our company generated location code.

• You're not required to have reference IDs, but can have one or many per item if you wish
• This one will be the same across your tenants

 

3. External IDs

 

I am rather digging this one, as we built a custom page in psoft that does basically the same thing.  :) Let's say that you have your NYC location with a Reference ID of 12345, but your payroll system requires a leading zero there, so you need to send 012345 to payroll.  In a psoft vanilla world, you'd hardcode that into your SQR or app engine, to append a 0 as a part of the interface.  WD allows you to set up this code on the location itself, so your user online is creating the location and then adding a row to set up 'Payroll System X' = 012345.  Then, the developer only needs to reference the 'Payroll System X' row when building the interface.  

It's also nice that you can have multiple External IDs for various systems, so if you have 10 different downstream systems that want 10 different codes for our NYC office, we can set that up on the location.

4. Then other tables have different 'code' options.  

 

Let's look at Ethnicity.  WD delivers some sample values, but you're free to configure your own:

Interesting to me here is that you can set up the 'map to' option.

Overall thoughts on IDs

We're still in the early days of being live with WD in the US.  Most of our integration consultants seem to be learning WD as they develop our interfaces.  

 

In general, I suspect we're not setting things up in the most efficient manner.  Like often in WD, its flexibility appears to be our undoing, but we've only figured out after the fact in some cases how we actually *should* have set things up.

 

However, there are definitely more options here than in PSoft, so I like it from that angle.

It will be a bit of a learning curve as currently we're in the midst of HR transformation, so folks who never maintained (or knew about) the codes needed by payroll will now need to be aware of them in order to maintain them.