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. 

Wednesday, 26 August 2015

Divesting a population off of Workday?

Looking for some feedback from those who may have done this task before.  Please leave me a comment or send me an email if you'd be open to a short chat or email conversation if so.

Thank you.

Sunday, 7 June 2015

Workday demo tenants

An interesting one I recently learned about...Workday offers what they term a 'Shared demonstration tenant' (to the named support contact at a customer site only).

It's basically a sample database with a limited number of user ids which is shared across the spectrum of Workday customers.  Workday provides this so that customers can see sample configurations, i.e. it's not for training or running a full business process, but rather for an occasional lookup, such as if you're thinking about implementing some new functionality.


  • You can use this sample tenant to access sample configurations without having to pay for your own tenant.  Remember, WD (like most other Saas providers) charges per tenant.
  • This is great if you're thinking about increasing your usage of functionality within HCM, for example, but as well if you only had HCM and were considering a complete expansion into another area such as Finance.  You can roam freely on your own, without being bothered by sales consultants filtering the information.


  • As WD says, it's only a demo tenant with limited functionality.  It's not meant to prototype the full business process.  For example, it doesn't do proxy, nor can you make your own IDs!
  • You're sharing it with lots of other customers.  If someone puts something ridiculous into it, you don't know if that comes from WD or another customer.
  • It's refreshed every Monday and potentially during the week too, if things are broken.  Work quickly!


My take:

  • I like it!  I come from a world where if you want a 'sample' set of configurations, then you're implementing a PeopleSoft vanilla database.  As we all know, databases take up space, i.e. cost, and vanilla is the first to go when we need to implement a training database.
  • You're depending on the "Named Support Contacts" to not share this log-in info willy-nilly, which I think is a reasonable assumption for such a position.
  • It provides value to customers.  You're not forced to take on the additional charges of an additional database when your usage is only going to be occasional.