- Well Built Solutions Newsletter
- Posts
- đđ Custom Objects Part 4: Your custom data's in Workdayânow what?
đđ Custom Objects Part 4: Your custom data's in Workdayânow what?
Read time: 7 minutes
Hey, hey! Ceci here.
Today, we continue our custom object series!
So far, weâveâŠ
â
Made the case for why custom objects matter
â
Gotten under the hood of setup mechanics
â
Learned how to get your custom data into Workday
And now, itâs time for the fun part: seeing, using, and maintaining it.
Being someone whoâs super into styling, this is the part that comes after adding a new piece to your wardrobe. The custom object is in your [data] closetânow itâs time to display it, pair it, and put it to use đ

Is it a staple? A showstopper?
Weâll see! Vamos!
You loaded the data⊠where did it go?
By default, all custom object data lives on the Additional Data tab of the business object you extended.
You can access the tab in one of two ways:
1) From the objectâs related actions menu > Additional Data > View All

2) Directly on the objectâs profile, wherever the Additional Data tab is placed

If you donât like where the tab shows up, thereâs good news! You can control that.
Run task Configure Profile Group, then select the Profile Group where you want the tab to appear.

In the resulting table, click the â+â icon, search and select the Additional Data tab, then situate it in the order you want it to appear.

In this example, the Additional Data tab is configured as the second tab on the Job profile group of the Worker profile.
Repeat this task for the profile group you want to remove it from, clicking the â-â sign on the line item with the Additional Data tab. If you donât, the Additional Data tab will show up in two places.
Use Custom Reports to replace the Additional Data tab
Now, hereâs where weâre gonna make a switcheroo on youâŠ

We actually donât like displaying the Additional Data tab at all đ€Ș
Hereâs whyâŠ
Custom objects are meant to fill your unique data gaps. But when youâve got more than one on the same business object, theyâre often totally unrelatedâlike comp data, drug test results, and dietary restrictions for workerâall mushed into the same tab.
Sure, security controls who can see what. But for folks with access to multiple custom objects (hello admins đ), it becomes a disorganized mess.
Instead, hereâs what we recommend:
Remove the Additional Data tab from the profile entirely.
Create a custom report for each custom object you want to display on the profile.
Add a filter/prompt for the object your custom object extends.
Share the custom report with the same security groups who have access to the custom object.
Add the custom report to a profile tab that makes contextual sense. For example, put the custom report for the custom object âExtra Comp Cycle Dataâ under the profile group âCompensationâ.
This way, youâre organizing custom objects that you want to display on the profile by where they belong!
And remember: Even with the tab removed from the profile, admins and users can still access Additional Data via related actions. It just doesnât need to be a front-and-center smorgasbord. Move it backstage.
Sold?
Cool. Hereâs how to set it up!
As examples, we use the custom objects âCommuteâ, âRisk Assessmentâ, and âDrug Testâ each built on the Worker object.
How to create a Custom Report for Custom Object data
Run the task Create Custom Report.
Give the report a name that resembles the custom object. This becomes the name of your eventual profile group tab.
Select a datasource that connects to the extended object. In this case, we select âAll Active and Terminated Workersâ to report on Worker custom objects.
Select âAdvancedâ as the Report Type. This creates a table that most closely resembles the custom objectâs form display.

Now, add your custom objectâs custom fields by clicking the â+â sign to add columns.
For non-effective dated custom objects that do NOT allow multiple instances, you can access the custom fields right from the object.
For example, the non-effective dated custom object âCommuteâ has a custom field for âDistance (meters)â. Since it does NOT allow multiple instances and thereâs only one possible instance value, you can search and select this field directly from the Worker business object.

Custom fields on custom objects that do NOT allow multiple instances can be accessed directly from the extended object.
đ NOTE: There are times your custom field may have the exact name as a delivered field. Use the fieldâs related actions to verify the field you selected is part of your target custom object.
For non-effective dated custom objects that DO allow multiple instances, access the custom fields from the related business object that the custom object creates.
For example, the non-effective dated custom object âRisk Assessmentâ allows multiple instances. Replace the default Worker business object with the Risk Assessment multi-instance field to access its custom fields.

Custom fields on custom objects that DO allow multiple instances can be accessed via the related business object the custom object creates.
đ NOTE: If you want to pull a certain instanceâs values, you can create an ESI/LRV pair to report on it.
![]() | ![]() |
For an effective-dated custom object, itâs a bit trickier.
Custom objectsâ fields common to an extended business object share a related business object for the object they extend. For the Worker object, this is âWorker Additional Dataâ.

Custom fields on effective-dated custom objects all share the same related business object of the object they extend. The two fields âLast Functionally Updatedâ and âEffective Dateâ are delivered.
Keep in mind, this reporting setup gives you a snapshot of the data as of the effective date you run the report for. For example, if we run our custom report with todayâs effective date, weâll only see the most current results for our âDrug Testsâ custom object.
If you want to report on those fields directly from the Worker business object, you can create LRV calc fields.

To report on the history of these effective-dated custom field, build a report on the associated event business object like âWorker Business Processâ. Then, leverage the related business objects âWorker Additional Data - Currentâ and Worker Additional Data - Proposedâ in a similar fashion.
Add an object filter/prompt
To make the custom report available as a profile tab, you must add a relevant object filter/prompt to the report.
In the examples above, the object is Worker. Pull the object into the field input, then set the Operator to âin the selection listâ and the comparison type to âPrompt the field for the valueâ.

When the report is added to a profile group, Workday automatically filters the report for the worker whose profile youâre viewing!
To build a report with custom field results for more than one worker, just skip this object filter/prompt and build in the filter/prompts that are meaningful to your use case.
If you plan to send the reportâs output as an API, enable the report as a web service on the Advanced tab đ©
Add the custom report to a meaningful profile group
Next, use the same task Configure Profile Group to add the custom reports to a meaningful profile group.
In our example, weâve added the custom reports âCommuteâ and âRisk Assessmentâ to the âJobâ profile group.
We also added help text under the âMore Infoâ section of the custom report to remind users how to edit the data if need be đ

Custom reports display custom object data for âCommuteâ and âRisk Assessmentâ on the Workerâs profile under the profile group âJobâ.
Outside of your own custom reporting needs, there are also some delivered items you can leverage to maintain your custom objectsâŠ
Delivered Reports & Tasks
As you maintain your custom objects, there are 2 handy WD-delivered reports worth bookmarking: Custom Object Definitions and Custom Field Status Report.
Both reports prompt you to select which Business Object(s) you want to evaluateâjust like when youâre building a custom object.
Youâll see the same, familiar input pathways: Non-effective dated, Effective dated, and Business process type.

The difference? When creating a custom object, youâre choosing what business object to extend. Here, youâre choosing which business object to review. You can select multiple business objects at once đ
Custom Object Definitions
The Custom Object Definitions report should be your first stop when trying to get your arms around what custom objects have been built in a tenant.
The results show:
The business object being extended (based on your prompt input)
Total custom fields used (thereâs a 200 custom field cap per business object)
A list of all custom objects on that BO (in alphabetical order)
The settings and attributes selected for each custom object
The screenshot below shows the first 3 custom objects for the Worker BO (non-effective dated) with details.

The report âCustom Object Definitionsâ report run for the Worker (non-effective dated) and Worker (effective-dated) BOs.
The Business Object prompt is optional. If you leave it blank, Workday returns every custom object in your tenant. Depending on how long your orgâs been live (and how trigger-happy folks have been with custom builds), it could return a ton of results. So, if youâre trying to zero in on something specificâitâs best to leverage the prompt.
Custom Fields Status Report
The Custom Field Status report is handy for taking quick inventory of your custom field counts and statuses per business object.
The output gives you counts for:
Draft fields
Active fields
Inactive fields
Total fields
In the example below, weâve selected the Worker (non-effective dated) and Job Profile BOs.

To see what custom fields are behind the count, click the hyperlink. The dialog box shows its custom object, field label, type, validations, and usage count.

Unlike the last report, the Business Object prompt is required. So to view all business objects in one go, select everything in the prompt.
Hereâs a quick shortcut:
đ Mac: Cmd + A + space bar
đȘ PC: Ctrl + A + space bar
Between these two delivered reports, you should gain a grasp on your existing custom objects in the tenant.
One more!!! đ
We said âfinal stretchâ last week⊠but turns out that was just hump day in whatâs now a 5-part series on custom objects. We just have too much good stuff to share!
By now, you know when to create custom objects, how to build them, how to populate them with data, and how to actually maintain and use them.
Thereâs just one piece left: how to retire them.
Next week, weâll talk about how to decide if a custom object is earning its keep in your [data] closetâor if itâs time to let it go.
See ya then! đ
As always, thank you for being a reader!
Weâre celebrating you and your pursuit of a Well Built Workday đ„ł
Until next time!
Ceci & Mia
Co-Founders of Well Built Solutions
P.S. Loving the newsletter? Leave us a testimonial here đ„°

Say hi đ on LinkedIn â @ceciblomberg, @miaeisenhandler
Reply