Customization in Workday - Custom Objects

As a SaaS solution, customer customization of the Workday application is limited to the delivered customization options that you as a customer can configure, and mainly that involves the use of 'Custom Objects'.

Custom Objects can be considered as 'free fields' which you set up to use however you want.  They are attached to the various WD objects such as the Worker object, Location, Company, etc.

An example:
We have a manufacturing location in Europe that is required by law to issue safety clothing to the employee on a certain schedule, so every 6 months they receive a new set of trousers, every 12 months a new set of safety boots, etc.  This clock starts as of the employee's start date, so every employee would have a different date to get new clothing.  (Workday has some business asset/company property functionality so we might put it there, but we're just using this as an example.)  Our goal is to put all of this data into the system, to avoid the need to have any data in Excel, etc.

So your Custom Objects need to be applied to the Worker Object.  We need 3 fields: 

1. Type of Clothing (boots, shirt, trousers, etc. choosing from a dropdown/validated list)
2. Size of Clothing - needed for HR purposes, so that we know how many size 40 trousers to order for next year
3. Date received - this is important, so that HR can run reports in advance, to see when they need to provide the employee with new items.  In particular, we have a night shift and while HR rotates to try and provide a presence during some of these hours on some days, they need to ensure that the supervisor receives the clothing in advance, to avoid any issues with the union that contractual obligations are not being met.

So in our case, our data entry person would get to any entry screen like this:

Date Received:
Uniform Type:
Date Received:

They're quite easy to set up and configure, once you make the decision of how your fields should be defined.  You only need to define things like:  Field Label, Field Type, Prompts, Validation, Status, etc.

The above example took about 5 minutes to set up.  The key is knowing your business requirements.

So in thinking further about Custom Objects:

Advantages:

• You can set them up to meet your business needs.  For example, if you need to track something which is not typically found in an HR database, this is the place to do so. 
• There is some flexibility in how you set up these custom fields.  For example, you can choose to set them up with some validation values, or you can make them formatted as a date, etc.
• It's 'easy' customization that doesn't involve any development--it's merely 'configuration'.
• You can do EIB loads into these Custom Objects, if you'd like, to be able to load data.

Disadvantages:

• You can only apply custom fields where they are delivered at the object level.  For example, you can apply custom fields to the Worker object, so associate custom fields at the employee level.  Or you can apply custom fields to the Location object, so for any custom fields you may need to associate with a location. 
• However, if you have a custom field that is not associated with Applicant, Company, Customer, Job Profile, Supervisory Organization, or any of the other objects available. but instead a different object that does not have Custom Fields associated with it, you will not be able to use it.
• There is a limit of 20 custom fields per custom object!  This is a big one.  It means that you may only store up to 20 custom fields at the Worker level.  In my above example, this would use up 3 of 20 custom Worker fields, leaving 17.  At a global organization, this is insufficient for our HR needs.
• You can store up to 100 instances of a custom object in each instance.  In my example then, let's say that we are storing 5 types of clothing for a worker, and that each worker gets a new set of 5 rows every 6 months.  At 10 rows per year, we'll be out of space in 10 years.  Of course we can archive the data to Excel after a certain time to make room for more, but it would be nicer if we didn't have this concern.
• The data entry for the user isn't so nice.  The user does data entry on custom objects in a stand-alone area for each object.  The fields are not able to be integrated into the 'core' object in a logical fashion.  In our Uniform example, we need to count on the data entry operator to go to the Custom Object area for the Worker to enter the needed data.  This is a different menu item from Job or Personal Data, so easy for the entry operator to forget.

Final thoughts:

• I like the functionality, and how easy it is to 'customize' the system.  In our old ERP such new fields would involve a customer request, request approval, a functional spec, development effort, testing, test documentation, and a production turnover.  Creating these fields in WD is a much smaller effort. 
• We need the option for a lot more custom fields, or we need WD to better enable the application with more regulatory reporting and global fields.  In our implementation we are not able to use the fields for 'business needs' because we need to utilize them to hold regulatory data which is not addressed by WD.  It would be great if WD would increase the limit to say--40 per object.