Read time: 6 minutes

Hey, there! Mia and Ceci here.

Ever had a stakeholder ask to report on something and you realize… there’s nowhere to put that?

It’s happened to us many times!

So what do you do when your organization needs to capture data that doesn’t have a delivered home in Workday?

Like when you need to track “caregiver” status for benefits, or collect additional position restriction fields for managers to justify newly requested headcount 🤔

Maybe, you spin up a spreadsheet 😬 Or say the dreaded words, “we can’t do that”.

Well, before you do, hold up! We’ve got good news…

You’ve got options. And in today’s newsletter, we’re going to explore the strategy behind one that is tried and true, and comes with your base Workday subscription—custom objects.

Let’s get into it 👇

Before we dive into the what and why, let’s zoom out for a sec.

Workday uses an object-oriented model, which means it organizes data into different “business objects” like Worker, Job Profile, or Position.

Each business object has its own:

A custom object is a way to add your own set of fields to a Workday delivered business object, extending the object so you can capture and track data that’s unique to your organization.

The truth is… custom objects are old news. They’ve been around for over a decade.

So basically… dinosaur functionality, in Workday time 😅

In the early days, custom objects were the go-to solution for any scenario where Workday didn’t have a delivered place to store the data.

But as the list of use cases grew, Workday responded—rolling out new config features that closed gaps we used to fill with custom object builds.

For example…

And those are just a few.

With every release, Workday expands the scope of its “delivered” solutions. So, before jumping into a custom object, pause to explore what’s already available. Sometimes, the cleanest solution is already baked in.

If what you need isn’t delivered (or you just plain don’t like how Workday delivered it— cough New Hire Provisioning cough), before automatically going the custom object route, you can also consider some fancier options…

One is Workday Extend. Extend can tackle just about any custom object use case (and way more) with a lot more glam—but that doesn’t mean it should.

And, it’ll cost ya 💰 Either in…

Another fancier option is everything else you can find in Workday Marketplace and beyond…

Think third-party solutions connected to your tenant via integration, packaged solutions loaded into your tenant (which may use custom objects anyway 😆), and more. There are plenty of third-party tools. Just walk through the Workday Rising Expo for proof!

These might solve your use cases more efficiently, more tactically, and yes—more beautifully. But, again… you will have to open your wallet, and your solution might not live in your “all-in-one” system. At the end of the day, you’ll make the best case-by-case decisions you can based on the circumstances and information you’ve got.

So, given all the options, why bother using (and learning) custom objects?

We’ve got three reasons for you:

1️⃣ They’re cost-effective.

Custom objects are native functionality included in your base Workday license. They may not have the “wow” factor—but they’re already at your fingertips, with no need to add a vendor, expand your tech stack, or build an integration. They get the job done.

Sure, there are better, more use-case-driven tools out there that absolutely drive efficiency, are smooth to use, and look prettier. But if all you need is a simple, flexible solution that lives inside Workday, custom objects are often the budget and time conscious way to go.

2️⃣ Governance capabilities are built in.

Every custom object can be assigned its own custom security domain or integrated into your delivered Workday security framework. That’s a big deal.

When Workday doesn’t offer granular security for a specific field or item (for example, Workday’s native “Other IDs” all share the same security domain), custom objects give you a way to isolate and store data with granular control over access and visibility.

3️⃣ They teach you how Workday works.

Custom objects are a crash course in Workday’s object-oriented model: You’ll engage with field types, business objects, and security domains. You’ll also start to think like a Workday architect as you consider how you might best bring disconnected data or processes from outside systems into your tenant in a clean and secure way.

Essentially, custom objects are a rudimentary way to make Workday flexible, helping you incorporate non-delivered data and/or processes into your tenant. Are they always the cleanest, most cutting edge solution? No. Can they get the job done fairly well within the product you already pay for? You bet.

Once your custom object is set up in your tenant, you can…

Now that we’ve made a case for custom objects, let’s discuss the strategy involved in deciding how to set them up.

When you run the task Create Custom Object, right out of the gate, you’ll make two key decisions, both driven by a single input—Workday Object. Your questions at this point are:

The answers to these questions determine (1) where your data lives and (2) how it’s stored over time.

To decide which business object you're extending, think about where the data naturally belongs. What is it describing? What is it connected to? If it’s worker-specific, you’ll likely extend the Worker object; if it’s tied to a job or position, you might use Position, Job Profile, or Job Requisition.

Now for how your data is stored over time…

Non-effective dated custom objects are not associated with an entry date or effective date—they’re simply stored values. When a value is updated, the previous one is wiped out. Unlike delivered Workday fields for which data changes are tracked through business process events, there’s no “current” vs. “proposed” version—only the most recent value is kept. These fields are updated with the Edit Additional Data task, which you can run from the worker profile, or, from the Additional Data tab on the object if it’s set up (via Configure Profile Groups).

A classic, historical example of a non-effective dated custom object is t-shirt size (many customers now use Configurable Fields for Personal Information to capture this, but bear with us for the example!).

You don’t need to track how a worker’s t-shirt size changes over time—that’d be a bit odd, right? 😅 You just need to know their current size, so you can send them swag for an event or new hire kit.

Workday lets you add non-effective dated custom objects to 71 different business objects.

To explore what’s available, follow the “Non-Effective Dated” pathway within the Workday Object input field as you create your custom object.

Effective-dated custom objects, on the other hand, are used to capture values that change and must be tracked over time. Updating them triggers a business process event, giving you distinct “current” and “proposed” values. These fields are entered and updated via an Edit Additional Data business process specific to the object the custom object extends (more on this next week!). You can run these BPs ad hoc, or add them as subprocesses to other BPs.

The limitation of effective-dated custom objects? Way fewer business objects support them.

Workday only allows effective-dated custom objects on 8 business objects (5 of those can also be used for non-effective dated custom objects).

So depending on what business object you’re trying to extend, you may not have the option to go effective-dated. In those cases, non-effective dated or a non-native solution (Extend or a third-party tool) are your best bets. For those who are highly cost and/or time-constrained, there is a workaround to jerry-rig an effective-dated custom object via a non-effective dated custom object. However, it’s only viable if the data won’t change too often.

Let’s look at a few examples where effective-dating is helpful…

If your organization employs drivers who undergo monthly drug testing, you may need to store a pass/fail result with a timestamp. An effective-dated custom object allows you to associate each test with a date and keep a complete history over time. This is especially useful when tied to compliance processes that trigger follow-up actions.

Another use case?

Tracking employee-assigned equipment. If your organization issues laptops, tools, or uniforms, an effective-dated custom object on the Worker object lets you capture what was issued, when, and whether it was returned. This provides a clear history for IT, Facilities, or HR—making offboarding smoother and inventory audits easier. The inbox task that an Edit Additional Data BP triggers offers more accountability compared to a To Do step for a non-effective dated custom object.

There’s a whole lot more to discuss when it comes to custom object setup. Next week, we’ll dive deeper into supporting mechanics like data entry methods (manual and EIB), custom object validations, viewing data, and more.

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!

Mia & Ceci

Co-Founders of Well Built Solutions

P.S. Loving the newsletter? Leave us a testimonial here 🥰