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

How to create a calculated field in Workday

I was having a discussion recently with someone, about the calculated field functionality in Workday.  I've previously posted about procedures and tips around using calc fields in an operational capacity, but I recently put together this quick example to explain the topic further, so thought I'd share it here too.

Once you're in Workday, the first thing to do is to define the type of calc field that you'd like to build:

There are many different options, more than I'm showing here, but the point is to know what you are seeking to do.  An average, untrained user would probably be stopped at this point.  Let's keep it simple and do a concantenation example.  It's also relevant to note--you need to know what business object should be invoked here.  We'll use the Worker object, since it's a main source for employee data.

On the next page, you're brought into a screen that functions in the same manner as the 'normal' reporting page.  So you can choose your fields, as well as add in the more intense logic if you're building something more complicated.  In my example, I just want to concatenate two fields together.  I'm using email+mobile just as a sample, so that I get a mix of letters and numbers:

Next after you save your new calculated field, you can use it in your reporting.  You need to choose the same Object (in our case Worker), to be able to find the field.  Then, your new calculated field will exist like any other field on Worker.

Then, you're ready to run your report.  Here's the example which I then ran into Excel:

 

 

A few points (and the reason I included a snippet of the output)...you'll see some workers have only a phone or some have only an email...so this is all you get.  So getting a good output on a calculated field will depend on what data you have to work with underneath it.  You can see where these can get tricky then as well, once you make more complex ones...is your bad output due to bad design of your calc field or bad data?

 

This was a quick and dirty two minute example.  WD offers a 3 day/15 hour training class on the topic, to get really in-depth with the logic of creating these special fields.  However, seeing how easy it is to create them, you start to get an idea of how dangerous they can become, if not regulated.  

 

Calculated fields in Workday

An interesting feature in Workday is the 'calculated fields' functionality.

 

To quote WD, 'Calculated fields allow users to perform simple arithmetic, date calculations, text manipulation, logical expressions, retrieval of related data, and transformations of their existing data. You can use calculated fields in reporting, business processes, integrations, scheduling recurring processes, and other areas within Workday.'

 

It's a nifty little feature, as

• it gives complex power to the users in reporting, via an online interface where you build them.  (As opposed to having to write complex expressions with if/then statements, for those of us from a PeopleSoft world).
• it allows for 'cleaner' development, as a developer is also using the online point and click functionality to build these items, rather than writing code from scratch.
• they are convenient, since you only need to build them once and then can reference them in reports, integration, etc.

So as a practical example, if you are interfacing to various systems, let's say 'gender' and one system needs 'M' or 'F', another system needs 'Male' or 'Female', another system needs '1' or '2' and another system needs 'M' or 'W' (male/female in German would be 'männlich' or 'weiblich').  So in each instance, you'd create a calculated field to allow for the M or F or 1 or 2, etc.  Then, if these systems ever changed their coding, it would be a simple online update to change the interface.  It's much nicer than other systems I've seen where hardcoded SQL needs to get updated.

 

As well, you can do traditional if/then or 'evaluate' expressions.  So if an employee's hire date is more than 10 years ago, put >10 or that sort of thing. 

 

From a reporting perspective, it allows you to build user friendly reports in an easier manner than I've previously seen in other systems.

 

Where are they not so convenient?

 

Like much of WD, the functionality is very flexible.  If you don't have your business processes in order to support this flexibility, you're in for some issues...

 

In our implementation (being lead by a mainstream consulting partner, but supported by multiple offshore consulting firms), the main parter says that best practice is to implement WD by 'an iterative approach'.  Basically, we keep putting data in, seeing how it looks, then tweaking here and there what we're doing.

 

When the topic of calculated fields came up, our traditional approach was to try to standardise and lock down the functionality.  (We have 150k + employees and a large part of our business is manufacturing, so we live by documented processes, otherwise it's a free for all mess.)  Our consulting partner directed us that 'best practice' is to not standardize, as that would cause a bottleneck, and instead, each developer should be creating any/all fields needed.  Not quite sure that was the best way, in retrospect.

 

We have 200+ integrations that are being built (many offshore) as well as local development of reports that are also generating calculated fields.  As there is no clearinghouse or rules, people just make a new calc field rather than hunting for an existing one.  The Data Governance and Controls team is now quickly working to implement standards and structures as the count of calc fields has soared to above 1000.

 

An example

 

To put it into a practical perspective, I've been working on some reports recently, to support our HR colleagues who are looking at the data.  I was seeking 'Business Unit Descr' so I searched for 'Business Unit'.  The top field is the WD delivered one (is it descr?  code?  who knows).  The ones after are all our calc fields.  This is not all of them, as others created them as 'bus unit' and all sorts of shorter versions such as 'BU':



 

You can see where the standards of the Data Governance team are starting to come into effect, such as using 'CF' as a prefix for calc fields or 'INT' when an integration is involved.  If you have only a handful of folks using this functionality or creating reports, it might not be such a big deal.  However, we will ultimately have hundreds of HR folks in the system using (if not creating) reports, so this willy nilly lack of standards will be confusing for them, even if they are only running reports and seeing disparate field names.

Looking online at the Workday Community site, other companies are grappling with these very same issues.  (Sidenote:  I'm a little surprised that WD itself does not issue more guidance).  There is a 'solutions' section in the community where other WD customers can post their top tips and documents, to share with other companies.  The group at Brown University put together some really great documentation, but just to give you an idea of how extensive this calc field naming can get, here is a snippet of their rules:

 

 

 

In addition, another customer (who has been live for a while) has developed a series of reports for more what I'd call the 'structural' aspects of the system--so basically audits to keep things tidy and more efficient.  He also includes calc field review in his list of 30 reports, such as keeping up with the following:

My tip of the day

As you can probably gather from the above, calculated fields can get very messy, quite fast.  Not necessarily WD's fault as it's a side effect of the flexibility of the technology, but you need to have strong business processes in place to control the creation of these things.  So I'd suggest:

• Define who will create calc fields in the future.  Read up on Community, various customers have defined different ways for this to happen (HR Business users, HRIS, IT, etc.)
• Develop your guidelines and structure of how these items will be named and categorized.  WD does provide things like 'tags' to help you in classifying them.  Again, the Brown University guidance is a good start.
• Be prepared to do auditing on calc fields in the future, to be sure that your environment is doing well against your rules.

Training on calculated fields

It's probably worth a mention, calc fields is a 3 day/15 hour online course from WD, to give you an idea of the level of complexity that you can get into with them.  The pre-req is the Report Writer class (2 days/10 hours)