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.
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:
It's not the end of the world, but I seek to minimize data entry mistakes by getting clutter out of the way.
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:
- 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.