Monday, 1 January 2018

Name formatting in Workday

I am currently looking at Workday's name formatting. When a user logs to look at an employee's data or to enter a new employee they see a country-specific name format, like this one for the US:

Workday defines the name format for you by country. It is one of those 'it's SaaS you'll take what you're given' situations.

For my dear readers in India, the India name format is this:
  • Prefix, Given Name(s), Middle Name, Family Name, Local Given Name(s), Local Middle Name, Local Family Name, Suffix

For our friends in China, you'll see this when you enter a Chinese employee:
  • Title, Chinese Family Name, Chinese Given Name, Given Name - Western Script, Family Name - Western Script 
This structure looks great and you'll be consistent. No matter what company you're working at you'll always see the same fields per country.

Here's the name formatting challenges in Workday:

1. You cannot turn parts of a name on or off.

Some companies consider their payroll systems to be 'king,' especially outside of the US. If your payroll system only contains first and last name but not middle name, you'll need to add the middle name into the first name field instead.

When Workday does not let you hide the middle name field you'll be in a regular audit battle to get your self-service or HR users to put it into the first name field instead of the delivered middle name field.

Or you need to code around it, so that your interface to payroll takes the middle name field and concatenates it into the first name field.

In my perfect world the customer would be able to configure what fields they would like displayed per country.

2. Workday dropdown values are not delivered.

I had thought that one of the advantages of a standardized SaaS would be to deliver standard values such as the name prefixes like 'Mr.' and 'Mrs.' This isn't the case, they are defined locally in each tenant. In theory, you set these up during your initial implementation and never touch them again. It becomes interesting if you do an acquisition or merger of two different systems however...

For the United States company A has 'Mr' set up and so does Company B. Each company has had to set up these values on their own.

It becomes interesting because the references IDs are different.

Company A set them up consistently using the full country names:

Company B used country codes instead, so they look like this:

At one point they started to add a 'w2' and 'w3' which was probably 'wave 2' and 'wave 3', so that we had 'MR_CAN_w2'. In a few cases they missed to add any reference ID so the system generated one for them.

The end result is a patchwork mishmash of inconsistent coding for the reference IDs which are used by integrations.

Company A and B need to go through an exercise to decide which values and reference IDs will be used in the future state and integrations need to be reviewed and revised.

I just don't understand why Workday doesn't deliver some of this stuff right out of the box.

Wednesday, 13 September 2017

Workday's new user interface

One of the things that I hear frequently is that users *love* Workday's interface. I can see why, it's easy and intuitive to use and pleasant to view. So I'm quite surprised that they're bringing out a new version of it. Here is a preview, the left is the current version that we know and love and the right is the future version:

My initial reaction is 'ugh!' It's called the 'canvas user interface' rather than the landing page.

Why is Workday making this change?

According to WD it will make for a consistent branding experience between desktop and mobile users. It will also allow for more branding by customers in mobile. On the plus side the blue that you see in the canvas can be customized in color, so if your key company color is red you can change that. Users will be able to set whatever color they want on their mobile devices however.

Also WD stated that the darker text will be easier to read.


Workday is handling the desktop experience separately from the mobile UI. Mobile is already in production. Customers can preview and use the new interface in desktop production but it's an opt-in. Everyone will be forced into using it as of WD 31 in Sept 2018. In the meantime your users are suffering through an inconsistent experience between desktop and mobile.

Customer impacts?

At least customers have a year to start changing any of their documentation, training materials or job aids. This is a major overhaul in the look of the software.

User opinions?

As I informally chat with HR systems people in my WD circle, no one is impressed. In the greater WD community people are seeing it as a step backwards. In particular people are wondering why WD is devoting so much time to making its product mobile friendly when so many users are desktop based. My personal favorite is the people who are comparing it to software of yesteryear like old Windows systems or *shudder* PeopleSoft 8. I actually see the PSoft comparison on the drilldown pages, plus the sample blue is similar to the PSoft blue.

Wednesday, 18 January 2017

Auditing Workday configuration - replication dates

I am receiving many emails in the past weeks about auditing Workday.  Workday offers courses specifically tailored for auditing professionals.  In case you are preparing for a WD audit, I'd like to share some of these solutions with you.

From the mailbox:

I am an Auditor and my client uses workday. I audited configurations on Sandbox and client mentioned that Sandbox is replicated from production environment but client was not able to show me how to see replication dates. 

Can you guide me , how to see replication date or configuration for replication (Prod > Sandbox)?

As a former IT auditor, these questions make my day.  Auditors are not dreadful people.  One of the key rules I've found with auditors is that 'there are many routes to the same city.'  Meaning:  as long as you can prove something to me, I don't care what method you use, as long as it is reliable. 

Question:  How do I prove when a Workday Sandbox was copied from Production?

1. Ask the customer to log on to Workday Community and print out the documentation that states mandatory sandbox refreshes once per week (it exists, including the timing).

2. Ask the 'Named Support Contact' (the person who can ask for/defer refreshes) to log on to Workday Community ad to go to the tenant management page.  Print this log.  It will prove that the customer did not put in any 'defer sandbox refresh' requests during your audit test period.  Therefore you can depend on the copy date as detailed in step one.

Sunday, 27 November 2016

Workday customer certification

It's been a year since I wrote about Workday's customer certification program.  As the fine folks at Workday sent me an unsolicited marketing email recently on this very topic, I thought I'd check in and see what's new on this front.  Specifically, let's talk about *customer* certification, rather than the general certification that Workday does for its own consultants and partners.

What is Workday customer certification?

Workday Pro is Workday's certification program for Workday customers, i.e. not the general public.  Customers can sign up their employees who take the WD training and tests to reach a level of knowledge that is similar to a certified partner.

Workday suggests that overall customers can get better value from their employees in the knowledge that they can deliver similar value on par with an external consultant.  WD suggests that employees can be recognized as having obtained a certain level of knowledge and can also access the latest and greatest update training that is only available to WD certified consultants.

How does it work?  

There are a number of certification tracks, examples:  WD HCM core, Benefits, Studio, Absence, etc.  For each there is a set of "Workday Pro" training.  So you pay for your training credits for a track and they give you a course, study guide and an exam.

IF you've already taken the equivalent 'regular' courses in the catalog it seems that will carry over.  You're still paying for the content but you're not required to utilize it.  The main thing in this case would be the exam. 

The clever marketing minds over at WD went through their training records and figured out I would qualify for a few certification tracks based on the courses I have already taken, so this was the gist of the email they sent to me.

Would I like to become Workday certified?

No.  I've been certified in a number of schemes over the years:  HR in the UK (CIPD), HR systems in the US (IHRIM), plus a number of extra ones in the information security space.  Here's why I wouldn't do it:

1. I cannot in good faith ask my company to do a second outlay of cash.  It's already enough money to take the courses the first time.

2. It's a multiple choice and true/false test.  I don't put huge stock in multiple choice tests, in particular when exams are not overseen and anyone can be taking it on the other side of the computer.

Should you become Workday certified?

I've recently received this question a few times via blog email in various formats such as WD consultants going in-house.  In particular, I'd say 'Yes!' if any of the following apply:

1. If you have not taken the courses and your company is willing to pay for them and for you to become certified, why not?

2. If you are coming from a completely different technology and branching into WD.

3. If you are working in a country that is known for offshore activities, it may be a way to distinguish yourself.

Would I particularly hire someone who is WD certified over not?  

No. While I am quite good at multiple choice and true/false tests, I don't care if anyone else can do them.  More important to me is someone's ability to follow a logical thought process and to understand HR business processes.  However, I imagine my more technical counterparts would prefer a coder who has gone through this process to prove a level of knowledge.

Other reading on this topic, how difficult is it to pass the exams?

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

Saturday, 16 April 2016

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.


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.

Wednesday, 2 December 2015

Good morning Workday Rising Dublin!

It's an overcast day in Dublin, but great to see the Workday energy here, from the signs decorating the airport doors to the buzz at the convention centre.

I have a full schedule of interesting looking sessions.  I mainly focused on global customer ones (as opposed to ones led by Workday resources), but did slip in the UK payroll one out of curiousity.

Like last year, I'll take some notes and share them here.