Workday Custom Objects in Action

Workday Custom Objects (CO going forward here) are easy to set up and configure, but how about from a user or data entry perspective?  Here we go:

1. You can access from multiple points on the person's record (see red boxes, for Additional Data menu).  It's nice that you have multiple paths to the same place:

 2. Once you've chosen the menu, you are then given a choice of which Custom Object you'd like to use.  In some ways, this isn't intuitive for the user at this point.  It's basically a collection of all the active Custom Objects.  So the data elements themselves are not related to each other (Apparel, Commute, etc.).  It's just a collection of 'Workday doesn't have these fields so we've created them' and stuck them in one place.

In my perfect world, I'd want to put 'Commute' with the Address data, for example.  Why?  We use the 'Commute' CO to track distance from home to work.  In Europe it's often woven into taxable benefits, such as when someone receives a company car or fuel benefit.  The greater the distance, the bigger the taxable benefit.  So if the data entry person is entering a new address on an employee, they need to remember to come over here and update the Commute value as well.

The Data Entry Pages

3. Since we spoke about Apparel in the setup example, let's stick with this one.  So here is the CO on Apparel, from a user's perspective.  It's pretty easy to choose an apparel type and size:

 

Keep in mind, this is Workday delivered sample data.  It's helpful for seeing how Workday envisions the pages to work if you're in a demo environment.

I'd like to point out a weakness about CO functionality however, using this example.  While we all say how we support standardization and global processes, I'd be much happier with this page if we could limit or apply the values to only certain regions or countries.

As you can see, it's one field with one big dropdown list.  (CO security is driven when setting up the object, so I'm not worried on that front, that a data entry operator would not have unauthorized access).  However, looking at this Apparel example, sizes vary around the world.  For example, if i were to buy a pair of shoes, I'd have to know my size:

US:  7.5     UK:  5.5    Europe:  38

Sizing is not a universal concept.

Workday does not let me limit this pick list in any way, shape or form.  So data entry folks around the world are left with this big list.  The only thing you can do is to make sure you think ahead and apply smart coding when setting up the values.

So the shoe pick list would either need to start the values with a region or country code:

US 7.5

US 8

UK 5.5

UK 6

EU 37

EU 38

OR we'd need to make the mapping and plunk everything into one line, so that our pick list looked like this:

US 7.5 / UK 5.5 / EU 38

US 8 / UK 6 / EU 38

etc.

It's not the end of the world, but I seek to minimize data entry mistakes by getting clutter out of the way.

Error messages

Workday does come with built in functionality, it's smart enough to know when I'm trying to enter a duplicate.  Would be happier if it was a little friendlier out of the box, however.  With that dollar sign in the error box, it looks a little clunky.

User specified validation rules

Workday does allow you to put on validations, so if the data entry person enters a wrong value, you can trigger an error message to inform the person to enter more appropriate data.  This is the closest I can get to ensuring that correct data entry is done (since I cannot limit the list overall on the front end).

So let's say that a data entry person accidentally chooses an incorrect value from the pick list, here is the error message:

 

Here is how it gets triggered.  The functionality of setting condition rules is consistent throughout the application, so if you know how to do one of these from the business process page or reporting pages, you know how to apply it here too.  Same functionality.  On one hand, I like the consistency for the back office folks setting these up:

As well, you get to specify your exact message in such a scenario:

From a front end user perspective though, I'd rather that the data entry operator not see the value in the first place, rather than have to go through a big dropdown and accidentally choose the wrong one, and then have to re-enter the data.  Fully understanding that this is sitting on the overall WD platform, however, so it needs to use their existing tools.  I'm just saying I'm not overly happy with the lack of limitation possibilities and having to build in validation rules after the fact.  But I get that this is how the application works.

Overall:

• It's a 'configuration' rather than 'customization' option, so good from that perspective.

• The user experience isn't as slick as the rest of Workday.  Trying to incorporate COs into the app seems patchwork and haphazard.

 

• You have the option to use Effective Dated COs, at least for Worker.  While it would be great to have additional ones, Worker is the most critical.

• Big Disadvantage:  Currently you only get 20 of these per business object (such as Worker), unless you're a Big Data customer, then you get 100.  As someone pointed out on the WD Community site, this obviously isn't a technical application limit since it is granted to some customers.  There has been a brainstorm out since 2012 to increase those counts for us non-Big Data peons, and according to the site it's targeted for WD 23 (Aug 2014 in Production).  Fingers crossed that this will open up more possibilities for us.

 

• Another disadvantage:  Lack of integration into the Business Processes from a data entry perspective.  My HR colleagues who are more on the front end of process design try to avoid these Custom Objects whenever possible.  They like a process to flow along in a logical manner and give much thought into how and where the data gets entered.  They like to set reminders and make things as foolproof as possible.  The location of this data under the 'Additional Data' menu leaves it as a bit of an orphan, a collection of 'extra' data items.  They prefer to instead cannibalize existing unused fields on the pages where data entry is occurring (shudder!) so that the data entry can be in one place.  

 

Any other options?

The eloquent Naomi Bloom suggested on Twitter that I think some more on this topic and WD's options.  Custom Objects are really WD's main mechanism in the way of user-defined fields.  As you can see, it can be a powerful option, in particular if you are used to a non-configurable environment.

There is one more option that we've been pulling out of our sleeve, using 'Custom ID' functionality.  If COs are the powerhouse of user-defined fields, Custom IDs are next best option if we want to cannibalize and re-purpose something.  I'll put together a separate post on that one.  To be honest I'm not really proud of how we're using that one, as we're stuffing data into fields in a way that was never its intended purpose, but in the interest of full disclosure, I'll show you what we're misusing.  In particular, we were afraid of using up our CO allotment of 20, so we've had to go the Custom ID route to store additional data, but from a systems standpoint, it's less than exemplary.