🌞🏗 Custom Objects Part 5: Custom objects—when and how to get rid of 'em

Read time: 6 minutes

Hey, hey! Ceci here.

Today, we’re wrapping up our custom object series.

Whether you’re new here (welcome! 😄), or have been with us on this custom object journey the past few weeks, here’s a quick recap of what we’ve covered so far:

✅ When to use custom objects (and when not to)
✅ How to set them up
✅ How to get your custom data into Workday
✅ Tips & tricks to best report on and display that data

And now?

We’re talking about how to get rid of ‘em.

The truth is, Workday evolves. Your org evolves. And when that happens, the shoe that was your custom object workaround might not fit anymore.

We’ve got good news for ya! You’re not stuck with every custom object you’ve ever built.

And, we encourage you to retire old config that’s not serving you. No need to let it sit and rot ☠

So—maybe you’ve caught wind of a newer feature that could replace your custom object? Well, before you sprint off to build it, pause (and read this newsletter 😉).

Here’s how to move on cleanly and carry your data with you


1. Inventory your custom object’s usage

Believe it or not, the first step isn’t jumping into config. It’s figuring out what your current object is actually doing.

Custom objects tend to have tentacles 🐙 They sneak into reports, condition rules, integrations, business processes—you name it. So before you cut them loose, you need a full map of where they’re being used.

Run the task View Custom Object and select the one under investigation đŸ•”đŸ»â€â™€ïž Then, click the “Usage” tab.

Here, you’ll see the custom fields and where they’re being used. But keep in mind—that’s just the top level.

Let’s imagine you’re reviewing a custom object, “Commute,” which has just two fields: Distance (meters) and Duration (seconds). We can see on the Usage tab these fields are used in arithmetic calc fields to convert the values into kilometers, miles, minutes, and hours.

But those calculated fields get used in reports, rules, or eligibility logic elsewhere!

Each object (like a calc field) has its own Where Used tab. So don’t stop at the surface. This is just the start of your rabbit hole. Follow the trail all the way down to where this data is displayed, referenced, or driving behavior.

For example: “Commute Distance (km)” might be used in a compensation eligibility rule to determine if a worker qualifies for a gas stipend.

Look for usage in:

  • Custom reports

  • Calculated fields

  • Condition rules

  • Integrations (EIBs, Core Connectors, Studio)

  • Business processes (steps, conditions, approvals)

  • Security groups or domains

Then, create an inventory and get specific. For each use case, ask:

  • Is this still active or needed?

  • Will you need to re-create this behavior elsewhere?

  • Can it be retired completely?

This step gives you the full picture. It clarifies what kind of cutover work you’re actually signing up for.

Think of it like spring cleaning! You can’t reorganize until you know what’s taking up space đŸŒ·đŸ«§

2. Explore and compare your options

Now that you’re crystal clear on what your custom object does and where it’s used, it’s time to explore what could replace it.

That might be a Workday-delivered feature (like Configurable Fields for Personal Information), a Workday Extend app (custom objects on steroids), or a third-party tool.

Each option comes with its own setup, strengths, and gotchas. So, ask these questions:

  • What configuration is required?

  • What kind of data can it hold?

  • Can it be reported on as needed?

  • Will it show up in tasks/BPs where users need it?

  • What are the security differences?

  • Does it support effective dating?

Make sure the new solution fully meets your needs before you commit. Be especially clear with your questions if you’re assessing a third-party tool, as there’s usually no “try before you buy” window.

Compare your potential solution with your current custom object setup. What do you gain? What do you lose?

The goal isn’t “shiny and new.” It’s ease—for both you and your users, now and down the road.

By the end of this step you should know
 is it time to break up with your existing setup? 😉

Important: It doesn’t have to be all or nothing. You can migrate just part of the object—offloading some fields, keeping others.

For example, one client of ours had 22 custom fields in a custom object for their Advanced Comp cycle. With better use of Workday features and calc fields, we trimmed it down to just 5 🙌

If that’s you, you might just need to inactivate some fields. Here’s how:

  1. Edit the Custom Object. Scroll to the field and click the “X” in its upper right corner.

  1. After inactivating, the custom field moves under the section “Removed (Inactive) Fields” with red x’s for clear visibility.

The status on the field will appear as “Do Not Use”, however, it can still be referenced across the tenant—"Do Not Use” will be appended to the field name.

If you do decide you want to upend your entire existing setup, keep reading!

3. Configure a proof of concept (POC)

Once you've explored your options and feel good about your direction, it’s time to test it with a POC—in a testing tenant, of course.

This only works if the solution is already available in your tenant—like a Workday-delivered feature, or a module you’re licensed for or have access to via a GMS tenant. If it's a third-party tool or add-on, this step may have to stay theoretical.

A POC isn’t the full build. It’s a focused test to see if the new solution can do what your custom object is doing today, and maybe even more!

As you build, focus on the essentials:

  • Use real test data

  • Confirm expected behavior

  • Check visibility: do users see the right fields at the right time?

  • Validate reporting, security, and edge cases

  • Test both data entry and downstream reporting

You’re not just replicating fields. You’re pressure-testing whether the setup works in real scenarios.

Let’s revisit our styling metaphor from last week: Your POC is a fitting room—not a checkout line. Try it on. Move around. Make sure it fits before you commit đŸ’ƒđŸ»

A strong POC helps you move forward with confidence—or shows you where to pivot while the stakes are still low.

It’s also your chance to catch the “gotchas” that are not always listed in the documentation or sales pitch.

If everything checks out, proceed to build the real deal 😎

Then, complete the cutover work you documented in step 1! Make sure every impacted and needed usage point is switched over to your new solution.

Proceed through the remaining steps with expediency


4. Extract and upload the data

Next up: move your data.

Start by building an advanced custom report for all your custom object’s current records (and historical data for effective-dated custom objects, as applicable). Export it as an .xls file. Capture whatever data needs to make the trip! ✈

Then, prep your data for upload. If you're moving your custom object data to something like Configurable Fields for Personal Information, use the available EIB to load it en masse.

No need to make workers re-enter info they’ve already shared—that just invites new data gaps and user error.

On the relevant integration system, click the related actions > Template Model > Generate Spreadsheet Template to format and upload your retiring custom object’s data into a new function of Workday.

Test your file with a small sample to confirm formatting and field mapping. Once it looks good, upload the full file and build a new custom report to validate the successful load.

This step keeps your history intact and your transition smooth 😊 

5. Purge your custom object’s data

Once the data is safely living in its new home, it’s time to clear it out from the old one.

⚠ Don’t take this step if you’re only inactivating a select few of the custom object’s custom fields as detailed above! There’s no option to select which fields to wipe out—it will remove all of them.

Run the task Delete Custom Object Additional Data, and select your retiring custom object. To delete the custom object for the entire population, keep the condition rule input empty.

On the next screen, scroll until you see the Confirm checkbox. Select it, and click OK. If you click OK before this selection, Workday fires an error. This is your fail safe. It can be a big deal to wipe out this much data at once!

To be thorough, also delete any custom reports that are no longer relevant. No one needs stale fields showing up in your search results!

6. Delete (or retire!) the custom object

Your new solution is live 👏 Your data’s been moved 👏 Now, it’s time to decide what to do with the old custom object. Here’s where it gets a little nuanced


First, know the rule: if your custom object still has data or its custom fields are referenced somewhere—like in a report, condition rule, calc field, EIB, or BP—you can’t delete the custom object.

Try, and Workday will fire back with a FAILED screen and a handy list of all the places it’s still in use.

Workday takes you to a FAILED screen when you attempt to delete a custom object with data or any usage across the tenant.

If you want to fully delete the custom object, you need to take your machete to this jungle and clear out all usages! Then, you’ll earn the SUCCESS screen.

If you need to retain configuration history, take the “retire gracefully” route đŸ‘”đŸŒ

You can keep a few usages (like past EIB loads) in place and cherrypick some of the actions below to effectively retire your setup


  • Purge the data

  • Inactivate all the custom fields

  • Remove all visibility (dashboards, reporting)

  • Replace the security domain with an Admin only domain

  • “Unhook” the object from business processes

  • Add “DNU” to the name of the custom object with a note of when it was retired

Pick your path! Either way, the goal is the same: ✅ Clean config ✅ No ghosts from old setups ✅ No head-scratchers for future admins.

That’s a wrap!!!

Well folks, that’s all for now for our custom object series 🎉 

You’ve learned when to build them, how to use them, and how to move on when it’s time to let them go.

Next week, we’ll take a beat from learning to be honest about where each of us are in our Workday journeys
 with some humor. I’m cackling just thinking about it đŸ€­

See you 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.