Read time: 3 minutes

Hey there! Mia and Ceci here. Hot take coming in hot today…

The Workday ecosystem has a quality-control problem.

We’ve spent the majority of our careers fixing Workday when it breaks. As first responders to thousands of Workday “accidents”, we know what good (and bad) configuration looks like.

The truth is, when something goes wrong in Workday, 99.99% of the time, it can be traced back to user error or configuration issues—legitimate bugs are rare.

This is what inspired us to found Well Built Solutions 🌞 🏗️

Our mission is to inspire an ecosystem-wide commitment to building Workday well.

Because truthfully, we’ve seen it built… uhm… not well, too many times 😳

So today, we’re sharing our thoughts on what makes a WELL BUILT solution!

Here are the 4 high-level questions we ask when developing solutions to ensure that our configuration is well built. No clever acronyms here (for now 😏)—just our uncomplicated way of confirming that our solutions will stand strong for years to come…

The solution will not be impacted by changes elsewhere in your Workday tenant. Dependencies upon upstream or downstream configuration are minimized to ensure that other configuration changes don’t break the solution.

The solution will grow with your organization. As configuration components are inevitably added over time, the solution will continue to stand strong to support your growing workforce.

The solution performs well with little to no maintenance. Using dynamic logic, the need for manual intervention has been minimized to reduce or eliminate administrative burden.

The solution is simplified and refined. Touchpoints with other configuration are minimized and logic is distilled into its most basic terms. The more straightforward the solution, the less likely it is to break.

🌞 🏗️

Building configuration well means thinking through potential solutions exhaustively. We never think of just one solution—we think of many, and choose the best one based on the criteria we just described!

A well built solution addresses the root cause of an issue. It doesn’t cover up breakage with a bandaid fix (i.e. a lazy remedy that builds upon existing configuration without addressing what caused the break).

Here’s a straightforward example to illustrate our well built principles in action…

You’ve been tasked with…

Building an announcement rule that will capture those who work at a location in the northeast. The northeast region includes these locations:

Here are two potential solutions. Can you determine which is well built and why?

Solution 1:

Solution 2:

If you selected solution 2, you’re spot on! Here’s why…

✅ It’s sustainable: If regions are re-evaluated and existing locations are moved into or out of the “USA - Northeast US” location hierarchy, the solution still works.

✅ It’s scalable: If the organization grows and adds new locations in the Northeast, as long as they’re added to the location hierarchy, the solution still works.

✅ It’s automated: If regions are re-evaluated or new locations are added, the solution still works. Referencing the location hierarchy makes this a dynamic, zero-maintenance rule.

✅ It’s elegant: This rule has just 1 condition line and 1 comparison value. The logic cannot be distilled down further.

In contrast, had you settled on solution 1…

❌ If regions are re-evaluated and existing locations are moved into or out of the “USA - Northeast US” location hierarchy, the solution becomes outdated (unsustainable). ❌ If the organization grows and adds new locations in the Northeast, the solution is no longer accurate (doesn’t scale). ❌ If regions are re-evaluated or new locations are added, an admin will need to manually update this rule (not automated). ❌ And is there a simpler way to build this rule? YES, there is (see solution 2 for maximized elegance 😆)!

As always, thank you for reading!

We’re celebrating you and your pursuit of a Well Built Workday 🥳

Until next time!

Ceci & Mia

Co-Founders of Well Built Solutions