🌞🏗 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


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

or to participate.