Sunday, 17 April 2016

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'.


  1. Thanks for the detailed summary.

  2. Thanks for the detailed summary.

  3. Thanks for the post, would like to suggest some content on WorkDay.