Workday Custom Objects in Action

Workday Custom Objects (CO going forward here) are easy to set up and configure, but how about from a user or data entry perspective?  Here we go:

1. You can access from multiple points on the person's record (see red boxes, for Additional Data menu).  It's nice that you have multiple paths to the same place:

 2. Once you've chosen the menu, you are then given a choice of which Custom Object you'd like to use.  In some ways, this isn't intuitive for the user at this point.  It's basically a collection of all the active Custom Objects.  So the data elements themselves are not related to each other (Apparel, Commute, etc.).  It's just a collection of 'Workday doesn't have these fields so we've created them' and stuck them in one place.

In my perfect world, I'd want to put 'Commute' with the Address data, for example.  Why?  We use the 'Commute' CO to track distance from home to work.  In Europe it's often woven into taxable benefits, such as when someone receives a company car or fuel benefit.  The greater the distance, the bigger the taxable benefit.  So if the data entry person is entering a new address on an employee, they need to remember to come over here and update the Commute value as well.

The Data Entry Pages

3. Since we spoke about Apparel in the setup example, let's stick with this one.  So here is the CO on Apparel, from a user's perspective.  It's pretty easy to choose an apparel type and size:

 

Keep in mind, this is Workday delivered sample data.  It's helpful for seeing how Workday envisions the pages to work if you're in a demo environment.

I'd like to point out a weakness about CO functionality however, using this example.  While we all say how we support standardization and global processes, I'd be much happier with this page if we could limit or apply the values to only certain regions or countries.

As you can see, it's one field with one big dropdown list.  (CO security is driven when setting up the object, so I'm not worried on that front, that a data entry operator would not have unauthorized access).  However, looking at this Apparel example, sizes vary around the world.  For example, if i were to buy a pair of shoes, I'd have to know my size:

US:  7.5     UK:  5.5    Europe:  38

Sizing is not a universal concept.

Workday does not let me limit this pick list in any way, shape or form.  So data entry folks around the world are left with this big list.  The only thing you can do is to make sure you think ahead and apply smart coding when setting up the values.

So the shoe pick list would either need to start the values with a region or country code:

US 7.5

US 8

UK 5.5

UK 6

EU 37

EU 38

OR we'd need to make the mapping and plunk everything into one line, so that our pick list looked like this:

US 7.5 / UK 5.5 / EU 38

US 8 / UK 6 / EU 38

etc.

It's not the end of the world, but I seek to minimize data entry mistakes by getting clutter out of the way.

Error messages

Workday does come with built in functionality, it's smart enough to know when I'm trying to enter a duplicate.  Would be happier if it was a little friendlier out of the box, however.  With that dollar sign in the error box, it looks a little clunky.

User specified validation rules

Workday does allow you to put on validations, so if the data entry person enters a wrong value, you can trigger an error message to inform the person to enter more appropriate data.  This is the closest I can get to ensuring that correct data entry is done (since I cannot limit the list overall on the front end).

So let's say that a data entry person accidentally chooses an incorrect value from the pick list, here is the error message:

 

Here is how it gets triggered.  The functionality of setting condition rules is consistent throughout the application, so if you know how to do one of these from the business process page or reporting pages, you know how to apply it here too.  Same functionality.  On one hand, I like the consistency for the back office folks setting these up:

As well, you get to specify your exact message in such a scenario:

From a front end user perspective though, I'd rather that the data entry operator not see the value in the first place, rather than have to go through a big dropdown and accidentally choose the wrong one, and then have to re-enter the data.  Fully understanding that this is sitting on the overall WD platform, however, so it needs to use their existing tools.  I'm just saying I'm not overly happy with the lack of limitation possibilities and having to build in validation rules after the fact.  But I get that this is how the application works.

Overall:

• It's a 'configuration' rather than 'customization' option, so good from that perspective.

• The user experience isn't as slick as the rest of Workday.  Trying to incorporate COs into the app seems patchwork and haphazard.

 

• You have the option to use Effective Dated COs, at least for Worker.  While it would be great to have additional ones, Worker is the most critical.

• Big Disadvantage:  Currently you only get 20 of these per business object (such as Worker), unless you're a Big Data customer, then you get 100.  As someone pointed out on the WD Community site, this obviously isn't a technical application limit since it is granted to some customers.  There has been a brainstorm out since 2012 to increase those counts for us non-Big Data peons, and according to the site it's targeted for WD 23 (Aug 2014 in Production).  Fingers crossed that this will open up more possibilities for us.

 

• Another disadvantage:  Lack of integration into the Business Processes from a data entry perspective.  My HR colleagues who are more on the front end of process design try to avoid these Custom Objects whenever possible.  They like a process to flow along in a logical manner and give much thought into how and where the data gets entered.  They like to set reminders and make things as foolproof as possible.  The location of this data under the 'Additional Data' menu leaves it as a bit of an orphan, a collection of 'extra' data items.  They prefer to instead cannibalize existing unused fields on the pages where data entry is occurring (shudder!) so that the data entry can be in one place.  

 

Any other options?

The eloquent Naomi Bloom suggested on Twitter that I think some more on this topic and WD's options.  Custom Objects are really WD's main mechanism in the way of user-defined fields.  As you can see, it can be a powerful option, in particular if you are used to a non-configurable environment.

There is one more option that we've been pulling out of our sleeve, using 'Custom ID' functionality.  If COs are the powerhouse of user-defined fields, Custom IDs are next best option if we want to cannibalize and re-purpose something.  I'll put together a separate post on that one.  To be honest I'm not really proud of how we're using that one, as we're stuffing data into fields in a way that was never its intended purpose, but in the interest of full disclosure, I'll show you what we're misusing.  In particular, we were afraid of using up our CO allotment of 20, so we've had to go the Custom ID route to store additional data, but from a systems standpoint, it's less than exemplary.

How to set up a Workday Custom Object

Around a year ago, I had written about my initial impressions on custom objects (Workday's 'customer defined' field options).  Still worth a read if you're looking for an overview of 'user defined' field concept in Workday.

Now that we're live in North America and into our European implementation, time to revisit the topic.

Today I'd like to focus on the logistics of setting one up, as I think this is one of Workday's strong points, the ability to easily create company required data fields.  Then later this week I'd like to look further at the nitty gritty of actually using them.

Rather than starting from scratch, let's look one up as it's the same page layout to enter or view (smart from a Usability perspective, the consistency).  You have a few options when searching, to filter.  Often we'd look by business object (similar to a 'table' in a traditional database setting, it's a grouping of related fields):

Most of our Custom Objects are tied to the 'Worker' Object in Workday.  The Worker Object is where we track something at the 'individual Employee' level.

Let's pull up the WD sample data, for the object 'Apparel'.  This is actually a useful one for us, as we are required to supply work shirts, trousers, etc. at some of our manufacturing sites, and there are repercussions if we do not provide replacements on the appropriate schedule.  If we were setting up a new custom field, WD walks us through the same pages:

Some useful things on this page, is that you can define the object name, validations, the field order, as well as specifying the security domain.  It's probably a smart idea to name these carefully, in particular, the 'web alias', as that is something that is not editable once a custom object is in active use.

Another feature I like overall about WD is the orange box you see here.  When you are on a Workday page, you can use it as a launch pad to other actions that you can perform on this 'thing' (be it a custom object, a foundation value, an employee, etc.)  Then you get a list of 'available actions' that pertain to the item that you are reviewing.  So in the case of this Custom Object 'Apparel', I can look up its integration ID, I can go report on it, etc.  Not exclusive to custom objects, but deserving of a call-out in any event.

Also on the page is the nice little summary, again on the page, I like being able to instantly see the security domains where this item is assigned.  Other colleagues doing some other tasks prefer some of the other fields summarized here.

In addition, there is a 'Usage' tab which is especially helpful if you're into reporting.  If you're planning to edit a custom object, seeing that it is currently included in a calculated field, for example, is quite helpful for impact analysis:

Last but not least, lest I always sound like a curmudgeon on Workday's lack of globalness in some areas, I must admit, I appreciate this global feature, to translate the Custom Objects into local language.  Two thumbs up!

So a few thoughts on the setup of custom objects in Workday:

• Very easy to do online!  It's 'customization by functional people'.
• I like the linkages and the displayed details.
• Overall, I think this is great functionality from the setup perspective, and recognizing that there is nothing existing in the PeopleSoft front in this area, except for proper customization.

Still to come:  Actually using the fields . . . is it still so easy?  Stay tuned . . .

A European solutioning example in Workday

As a global company, we have offices and employees in almost every country in the world.

Much of our North American Workday implementation was based upon US requirements, with a handful of Mexico and Canada business needs sprinkled in.  This design, configuration and use became 'the global footprint'.

Now that we're looking at European countries as part of our next wave of implementation, in general the current use is getting challenged.  In addition, the design is getting extended for business requirements that did not exist in the US, e.g. contract data.

What is European contract data?

 

First, I'm not talking about contractors.  :) In Europe, most countries have the concept of employment contracts, so prior to accepting an employment offer, the contract provides a contract offer to the candidate (i.e. future employee), and the candidate may choose to sign 'as is' or negotiate some of the contract clauses.  Then both the candidate and a company representative sign the contract to make it official.  Each country will usually have different things that they put into their contracts, depending on local business practice.  There is no 'Euopean contract'. 

For comparison, I've worked in three countries for the same company.  In the US I received an offer letter of 2 pages, it listed things like salary and work location.  In Germany, I received a 25 page contract with all of the employment terms and details spelled out.  In the UK, my contract was a little shorter, only 12 pages.

If you get a big promotion such as from non-manager to manager or to a high position, you may get a new contract.  Otherwise, for smaller promotions, your contract would just get an addendum with any new details.

What kind of data is in a European contract?

 

Often, you'll have some general and overarching principles that apply to all employees, such as an ethics policy or general details about working conditions.

A contract will often hold basic data, such as the employee's name, home address, and job data such as title/position, the title/position that the role reports into, weekly hours, pay frequency, pay rate, hire date, seniority date (if differing for benefits calculations), notice period, probation date, etc.

As well, you'll find some 'eligibility' items 

• if a company provides a contribution to a pension on the employee's behalf, what is the percent
• if a company car is provided, what is the level/budget or allowance in lieu of car
• holiday entitlement
• private medical scheme, if offered
• what sort of sick pay you are entitled to
• etc.

 

What is the Workday functionality?

Workday gives us a page for contract data, it looks like this:

• Workday has the usual 'per country' configuration, so that you can set up your Contract Types per country, which is helpful.
• The attachments and comments feature is also there, so that is useful if we want to attach a copy of the contract.

Some of the job-related data found in the contract will be on the 'regular' Workday job pages.  Other data such as pension or health, we can try to store on the benefits screens.  However...

Where we're challenged in Europe, trying to use Workday

There's a lot of great fields on this page, which we would definitely use.  But we're struggling to figure out where to put the rest of the contract data.  It's like we were invited to dinner and only served the appetizer.  My current thought is that this page was designed without European input.  Mexico does have more of a concept of contracts, so maybe that was the driver, who knows.

Here are some areas that are providing heartburn at the moment.  And specifically, our payroll systems in the countries do have the concept of contract data, and would like to receive it on an interface from Workday.  Our HR people as well would like to be able to store and view this data.  So where are the disconnects?

1. Notice period

 

This particularly pains me, as it's such a basic concept that any European based HR system would contain.  A notice period is included in your employment contract.  The higher your position, the longer it is likely to be.  None of this '2 weeks notice' in Europe!  My notice period in the UK and Germany has been 3 months.  High level executives may have 6 months or a year even. 

This applies to both the employer and the employee, and may differ, although if we could just get the employee one, that would be great.

Notice periods are often a 'date in words', for example:  3 months, 6 weeks, etc.  There is an added complexity to some, such as 1 month to the end of the quarter.  I've heard some other companies try to simplify and specify a number of day or weeks.

In addition, local labor law may specify a minimum statutory period, but as a company you may wish to put a longer notice period into place.

Workday has no functionality in this area!

There is a Workday Brainstorm (Workday's mechanism to make change requests to the application) from other companies to at least get a 'notice date' added.

2. Dual contracts

 

This comes up in various EU countries, in particular where we have better benefits than our NA counterparts.  :)  Often, an employee has a regular contract, and as a part of that may receive maternity benefits from either/both the company and/or government, depending on the country.

The employee on maternity may receive their regular benefits, but may want to work part time during maternity leave.  Usually in this case, the company will need to make a new contract with the relevant employment information.

Workday only allows for one active contract at a time!

Again, there's a Brainstorm to get this changed, or at least configurable to allow for two simultaneous contracts.

A workaround is to use Workday's 'multiple jobs' functionality.  If you put the employee into two distinct positions, the employee may have two active contracts at the same time.  However, that's a lot of work to enable, both from a functional and technical side, just to get some minimal contract data into place on a 2nd contract.

3. Contract renewal

In Europe, for better or for worse, it's more difficult to terminate an employee.  Often, we hire people on in temporary contracts.  Depending on the country, you are allowed to extend the contract a certain number of times, but after extension number x, it automatically converts the emp into a 'regular' contract (with all corresponding rights).

Workday missed to include this functionality!

Workday workaround:  Use the freeform 'Contract ID' field and get the data input folks to consistently put in '0001' for 1st contract, '0002' for 2nd contract, etc.  I don't like using freeform fields in this manner, as you end up doing extra auditing as people forget the 0's or make it length 5.

There's a Brainstrorm for this one too.

I could continue on here with my online gap analysis, but I think you get the idea.

Why is this especially irritating?

 

PeopleSoft has a lot more functionality!  Granted, we probably only using 10% of the fields on the pages, but they met our needs.  In my 'notice period' example above, we set up a contract clause for each notice period, such as the 'non competing' clause listed below.  As each employee has a contract, you then choose the relevant notice period clause for that employee.

In Summary

We're continuing to review the data against what our payroll systems need to receive.  As the contract data pages are not very robust in Workday, we'll be left having to 'MacGyver' it in, or not store it at all.

In discussions with our Workday certified consulting partner, the only thing they can tell us to do is: either don't store the data in Workday, or make custom objects, custom IDs etc. to accommodate it, recognizing that you don't have enough custom objects free to meet the needs.  As well, it would just be generally ugly from a data entry and reporting perspective, as well as not in harmony in one place, with some fields on the contract data pages and others independently as custom objects etc.

I think the irritation here is that we currently have a workable solution in PeopleSoft, and in going to Workday it's seen by the users a going backwards as Workday does not come to the table with a real solution here.

Pleasantly suprised: Workday's social media response

I occasionally take a break and log into Twitter, to see what is happening in other HR System topics around the world.

Last week, Workday had tweeted about an upcoming online event:

Announcing our 1st tweet chat! Join us on 6/19 from 10-11am PT using #WDAYchat. @LeighLevensaler will discuss Big Data for Better Recruiting

It sounded really interesting, but once again, I wasn't impressed with the lack of global thinking, from Workday.  So I tweeted a polite response to the timing of it.  6 PM on the European mainland, 1 AM Hong Kong next day, it's not great if you are seeking to reach a global audience.  Although fair enough if your focus is the US market.

I wasn't expecting much of a response to be honest (in particular as I'm not tweeting under some big company name, but as an anonymous blogger), but was please to see that Workday's Social Media Director quickly responded to me, in under an hour.

Thx for feedback. We plan to make this a recurring series, so future chats could be at other global times.

We'll also record & post this tweet chat via @Storify for on-demand viewing & to keep the conversation going!

Even though I'm still not impressed that Workday seems so US focused (especially when they could slightly back it up to 8 AM and get into the European workday), I was pleased to get a response.  From a customer perspective, while I'm not happy with the timing I am happy with how they handled my comment.