Making optional fields required in Workday

This is a subject that is near and dear to my heart.  I like a system that is user friendly and makes things as simple as possible for the users.  At the same time I recognize the dangers of system customization in particular during upgrades or when patches are applied and customizations must be re-done.  A few thoughts on this topic.

A brainstorm has been open on Workday's Customer Connection since March 2010 to allow for customers to configure when optional fields should be required.  It has received 982 votes from 483 companies since I last looked, so this is functionality that many customers would like to have.

I have followed this brainstorm over time.  On the surface it should be a simple request to allow customers to make an optional field required.  However, as customers chime in with use cases, it does seem a little more complex than that.

Requested functionality

• Make field X required as this is important to our company.
• Make field X required when Y is entered.  Example, make area code required when a phone number is entered.  (This one was later added as an optional validation that a company could turn on/off.  Some prefer to keep it off where they have internal speed dial codes.)
• Make fields certain required during a new hire but not during a data change.  Example, you can change a phone number without changing an address but upon hire both should be entered.
• Make field X required in certain countries.  For example, country of birth or nationality are relevant in France and Germany but not the UK.
• Make field X required for employees but not contingents, example:  birth date.
• Make certain fields open/not open for entry depending on the process and other sub-data elements

Advantages of having the ability to make fields required

• Integrations top the list.  One customer mentioning having to chase 2,000 data errors per month due to missing fields.  In particular customers are nervous that interfaces to payroll systems will error out.
• It's much nicer to stop a mistake at the time of entry instead of through an after the fact audit.

So how has WD progressed on this topic?

Feel free to jump to the next heading as this tired me just reading it.  The short answer is, no it hasn't been delivered but at least it's marked as a Candidate.

• Mar 2010   Brainstorm opened.  A lot of comments follow about how useful this would be for customers.
• Feb 2013   A WD employee thanks everyone for the ideas but mentions that no timeline is in place for delivery
• Mar 2014   Another WD thank you and no timeline message.

• Apr 2014   A Workday developer comes into the discussion to vet out some ideas and confirm the use cases.  (Not exactly sure if a developer or business analyst, but let's say developer for now.)
• Provide a mechanism such that optional fields in Workday that are not part of the BP can be marked as either required or not allowable for data entry.
• Offer the ability to mark the optional field with a red asterisk.  
• Make fields required depending on data entered in other fields.
• Suggesting that the country-specific requirement belongs to the localization strategy and as such is not a part of this request. 

• Apr 2014   Some more back and forth discussion with the developer and the developer's suggestion to have a call along with a voting mechanism to vote for a time.
• A grand total of 16 people from 10 companies attended the Pacific time afternoon session.  The requirements seem to expand further...good documentation from the developer of the call.  Requirements include:
• Hide not used fields from the user.
• When you hide the fields readjust the page to fit the fields instead of blank space.
• Allow optional fields to be made required on BPs as well as their corresponding EIBs.
• Automatically fill a field with a default value.
• Potentially allow for making fields required per organization.
• Confirmation that people wanted field control per business process rather than across the application.
• Expansion that per BP a field could be required, optional or hidden.

• May 2015  Customers kick start the discussion seeking an update.
• Oct 2015   Customers ask again for an update.  

• Oct 2015   The developer responds that they're looking at a phased approach starting in WD26.  Options include:
• Set the fields as required or hidden at an overall BP level (so the same required/hidden status in initiation, revew or approve).
• Set the fields as required per step.
• Queue lots of customer discussion about sub-processes and how the initiation step only is insufficient.

• Mar 2016   Another customer request for an update.
• Apr 2016   Another customer request for an update.

What is the workaround in the meantime?

1. Make a validation rule on a step of a business process.  We have done this but it's not the nicest solution.

• You do not get a red asterisk as in the delivered required fields so the user does not know it is required until it hits the validation step.  While power users will get used to regular entry self-service users need more system help.  In addition, some companies responded that once it hits the validation it can go into an error step and a manager loses all of the data entry done depending on their clicks.  Also the system generated error messages are not the best.
• Depending on your requirements, these validations can become numerous, so yet another thing to keep track of and test.

2. Another suggested option is to make a calculated field tied to an optional field which would address when something needs to be populated only in certain situations.  However, you're now maintaining another calculated field.

I am curiously awaiting the next update from Workday on this one.  As they say, 'watch this space'.

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.

Required vs non-Required fields in Workday

I've been looking further at the Disability data pages in Workday, and do these meet the need of the data required by the various country payroll providers.  Typical analysis tasks exist like you'd do for any system:

• Understand the business requirements, fit gap for the data elements
• Ensure that the data home is palatable for developers and report writers
• Make the data entry as easy, friendly and automated as possible for the data entry teams
• Think holistically, will this definition work across the countries?
• Consider long term, is the entry sustainable, will this be a self-service item, etc.

In essence, it's a balancing act of these various pieces, whenever I design a solution. 

Occasionally in PeopleSoft, an entry person has to put default data into a field to be able to get into a field that they must use, so be it.  On the flip side, if there is an important data element or one that if not populated will break an important interface such as payroll, we've been known to make the quick and dirty customization in PSoft to make the optional field required.  (Technically it's a customization, but an easy one to turn on the checkbox.  It's more of an effort due to our change management process to make/test this 'code change'.)

In looking at Disability in Workday, only the Disability code is required, none of the additional fields are required.  As a SaaS solution, there is no option to customize to make these fields required.  My issue here is that country-specific interfaces require a set of fields as mandatory for disability.

Where this is going to be a challenge for us:

• Like many companies in Europe, our Shared Services data entry team supports multiple countries.  
• Some data entry will always be country specific: Name formats, Addresses, Disability, Labor Agreements, Establishment for France, Brazil etc.  
• Often, it's consistent across a country, but the system just makes all the fields open.  Thus the 'Flexible' description.
• Fields can be entered/non-entered for a country
• Fields have no setup values behind them, they are free form

My concern is that in this example, Disability is not a daily entry task, and it differs greatly per country.  We cannot dictate entry at a system level, beyond giving an entry professional access to the page.  There are downstream, i.e. Payroll, impacts if the person does not do the entry correctly.

So we'll need to prepare entry documentation per country, that the entry person will need to look up and use each time they need to enter this data.  With WD's regular updates this will be a challenge to keep current.

While this item alone is not huge (we're not hiring a disabled person every day, although in some ways it would be better if they were doing the data entry every day, then the rules would be memorized), when you start to add up the various items that will require similar efforts, it starts to add up.  For fields that do not break an interface but are important for business reporting, it will become a matter of building audit reports and chasing up any 'required' fields when empty.

I realize this topic continues to come up on Workday's Community site, the ability to make a non-required field 'company required', and knowing nothing about the guts of Workday, I'm suspecting it's a pretty big ask since it's not getting picked up.  I am starting to get a little nostalgic for a non-SaaS HRIS though, as I consider:

1. Broken interfaces due to incomplete data
2. Additional auditing needed
3. Making extra documentation so that people know what fields are required.

Also fully recognizing that this is not a 'Workday' issue per se, but moreso a 'SaaS' issue overall, that configuration is limited to the vendor's offerings.

Customization in Workday - Custom Objects

As a SaaS solution, customer customization of the Workday application is limited to the delivered customization options that you as a customer can configure, and mainly that involves the use of 'Custom Objects'.

Custom Objects can be considered as 'free fields' which you set up to use however you want.  They are attached to the various WD objects such as the Worker object, Location, Company, etc.

An example:
We have a manufacturing location in Europe that is required by law to issue safety clothing to the employee on a certain schedule, so every 6 months they receive a new set of trousers, every 12 months a new set of safety boots, etc.  This clock starts as of the employee's start date, so every employee would have a different date to get new clothing.  (Workday has some business asset/company property functionality so we might put it there, but we're just using this as an example.)  Our goal is to put all of this data into the system, to avoid the need to have any data in Excel, etc.

So your Custom Objects need to be applied to the Worker Object.  We need 3 fields: 

1. Type of Clothing (boots, shirt, trousers, etc. choosing from a dropdown/validated list)
2. Size of Clothing - needed for HR purposes, so that we know how many size 40 trousers to order for next year
3. Date received - this is important, so that HR can run reports in advance, to see when they need to provide the employee with new items.  In particular, we have a night shift and while HR rotates to try and provide a presence during some of these hours on some days, they need to ensure that the supervisor receives the clothing in advance, to avoid any issues with the union that contractual obligations are not being met.

So in our case, our data entry person would get to any entry screen like this:

Date Received:
Uniform Type:
Date Received:

They're quite easy to set up and configure, once you make the decision of how your fields should be defined.  You only need to define things like:  Field Label, Field Type, Prompts, Validation, Status, etc.

The above example took about 5 minutes to set up.  The key is knowing your business requirements.

So in thinking further about Custom Objects:

Advantages:

• You can set them up to meet your business needs.  For example, if you need to track something which is not typically found in an HR database, this is the place to do so. 
• There is some flexibility in how you set up these custom fields.  For example, you can choose to set them up with some validation values, or you can make them formatted as a date, etc.
• It's 'easy' customization that doesn't involve any development--it's merely 'configuration'.
• You can do EIB loads into these Custom Objects, if you'd like, to be able to load data.

Disadvantages:

• You can only apply custom fields where they are delivered at the object level.  For example, you can apply custom fields to the Worker object, so associate custom fields at the employee level.  Or you can apply custom fields to the Location object, so for any custom fields you may need to associate with a location. 
• However, if you have a custom field that is not associated with Applicant, Company, Customer, Job Profile, Supervisory Organization, or any of the other objects available. but instead a different object that does not have Custom Fields associated with it, you will not be able to use it.
• There is a limit of 20 custom fields per custom object!  This is a big one.  It means that you may only store up to 20 custom fields at the Worker level.  In my above example, this would use up 3 of 20 custom Worker fields, leaving 17.  At a global organization, this is insufficient for our HR needs.
• You can store up to 100 instances of a custom object in each instance.  In my example then, let's say that we are storing 5 types of clothing for a worker, and that each worker gets a new set of 5 rows every 6 months.  At 10 rows per year, we'll be out of space in 10 years.  Of course we can archive the data to Excel after a certain time to make room for more, but it would be nicer if we didn't have this concern.
• The data entry for the user isn't so nice.  The user does data entry on custom objects in a stand-alone area for each object.  The fields are not able to be integrated into the 'core' object in a logical fashion.  In our Uniform example, we need to count on the data entry operator to go to the Custom Object area for the Worker to enter the needed data.  This is a different menu item from Job or Personal Data, so easy for the entry operator to forget.

Final thoughts:

• I like the functionality, and how easy it is to 'customize' the system.  In our old ERP such new fields would involve a customer request, request approval, a functional spec, development effort, testing, test documentation, and a production turnover.  Creating these fields in WD is a much smaller effort. 
• We need the option for a lot more custom fields, or we need WD to better enable the application with more regulatory reporting and global fields.  In our implementation we are not able to use the fields for 'business needs' because we need to utilize them to hold regulatory data which is not addressed by WD.  It would be great if WD would increase the limit to say--40 per object.