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 and divestitures

A few months back I asked for contacts who had divested a part of their employee population from a Workday instance into a spin-off company who would also be using Workday.  I am pleased that a large US multi-national responded and was able to share their insight on a call with me. I thought their experience was helpful, so here are my notes.

Background 

A large US headquartered manufacturing company in over 150 countries with 55,000 employees spinning off 15k of those into a new company. The 15k belonged to a line of business that was a niche specialization and employees were located at sites in 12 countries.

The parent company (let's call them company X for now) had freshly implemented Workday before the spin-off decision (let's call that one company S) was taken.

The direction was to maximize the speed of the work, there was no time for a fresh implementation from scratch.

How did it work? 

Company X worked with Workday to create a cloned instance which copied the configuration (BPs, security, setup data, etc.) without employee data and then extracted and loaded Company S employee data under a 1 week HR data freeze.

Employee data was loaded in S as “History from previous system” for comp and performance data rather than bringing over the job data as it exists at X

What took a lot of time?

It was big work to re-establish the supervisory orgs.  S chose not to clone as their organizational structure was brand new rather than a carry over from X.  For the other orgs S cloned location, cost center, etc. but then had X locations in the location hierarchy, for example, which were never S locations.

It took 6 months to get Workday to acknowledge S as its own company then 4 months to get an account manager and even further time to get one in its own region.

Staffing the team

While S brought over 15k of employees, most of the HR function was built up from scratch from new outside hires.   While there was a TSA (transitional service agreement) on the systems side to administer Workday for a time after the spin-off, S ‘tribal knowledge’ was lacking, understanding *why* WD was configured why it was.

There were 20-25 people supporting Workday at X prior to the spin (HRIS, IT etc.), but these jobs didn't go away post-spin as the support organization still had the same number of integrations to support, etc.  S began with 6 staff members and the TSA with the assumption that more would be hired post-TSA.    

Any call-outs that would be worth mentioning?

Post go-live there was 6-8 weeks of data stabilization just to make sure that the right employees were in the S instance.  Then  there was a longer project to get the X data de-activated in the S instance, such as those non-S locations, job profiles, etc.  This is a trade-off of the 'quick clone' method, that non-S setup data will always be in the S instance.

·