Read time: 9 minutes

Hey there! Mia here. I’m going to say something that will probably have you nodding in agreement…

Workday is NOT an “out-of-the-box” software ❌ 📦

And this is not a bad thing! In fact, it’s one of Workday’s major strengths compared to less robust tools. Your organization is unique and needs HR software that can be customized in a sustainable and scalable way.

Workday can do this super well… if you know how to set it up.

In today’s newsletter, you’ll get a detailed breakdown of how to configure boolean condition logic—a key building block for customization in Workday.

You’ll see boolean condition logic again and again in Workday. It’s the functionality that drives heavy hitters like…

And MORE! Mastering the ins and outs of boolean condition logic in Workday is your ticket to the customization party 🎉

So, if you don’t have your ticket yet, let’s get you one! The box office is this way 👇

If you’re confused and thinking to yourself, “Mia, of course I want in on the customization party but what in the world do you mean by boolean condition logic?” Don’t worry! Here’s some background…

“Boolean” refers to binary logic (i.e. only two possible outcomes)—computer programming at its most basic level. In Workday, True/False Condition calculated fields are often referred to as “boolean” fields.

Check out the screenshots below…

You’ll notice that the logic interface is nearly identical in each screenshot. The inputs for True/False Conditions, Report Filters, and Business Process Condition Rules, respectively, are the same! This is also true for much other functionality throughout Workday.

This interface (and its underlying functionality) is what I’m referring to as “boolean condition logic.”

If you missed our breakdown of True/False Condition calculated fields on LinkedIn and you’re unfamiliar with boolean conditions in Workday, we recommend checking it out as a prequel to this newsletter (FYI - the video is silent on the post!).

Alright! Without further ado, let’s get into the breakdown and master this interface together 🚀

First, let’s orient to the layout of the interface. From left to right, you’ll see the following 9 columns:

Let’s break down each column…

You can click the “+” button to add a row to your condition, and the “-” button to remove a row from your condition. Boolean conditions can, and usually do, have multiple rows. Each line is its own boolean condition, that lives within the overall boolean condition.

Use the 🔼 and 🔽 arrow buttons to change the order of your condition lines. These buttons help rearrange lines of logic when you’re working on a multi-condition setup.

The 🔽 arrow on the left of your first condition line (shown in the screenshot below) is special—it has a subtle extra line on top. This arrow moves a condition line to the very bottom of the overall condition.

The order of your condition lines impacts condition performance. This is especially important for the condition setup within the Filter and Subfilter tabs on custom reports—here, report performance, or the speed at which the report returns results, is impacted.

For best performance, when you have multiple lines of logic within your overall condition, aim to order the conditions from most to least specific, from top to bottom. You want Workday to filter out the greatest number of results first.

And/Or connects the lines of logic within your overall condition.

AND logic tells Workday that BOTH or ALL conditions must return TRUE for the overall condition to be true.

OR logic tells Workday that at least ONE condition in the set of conditions must return TRUE for the overall condition to be true.

Sets of conditions can be isolated within a larger condition rule using parentheses. Parentheses are typically needed when you’re mixing AND and OR logic within an overall condition.

As you may remember from our True/False Condition post on LinkedIn, the intentional placement of parentheses around sets of conditions can change the logic of the overall condition. For example...

(Worker Type is Employee OR Country is United States) AND Employee Type is Intern

...is NOT the same as...

Worker Type is Employee OR (Country is United States AND Employee Type is Intern)

Parentheses are powerful (use them carefully and intentionally 😉)!

The *Field (labeled “Source External Field or Condition Rule” in some contexts) is the subject of your condition—the main star. ⭐️ It’s what your condition is about. The asterisk means this is a required input.

In a calculated field, your Field can be any field on the business object on which your calculated field is built.

In a Filter, your Field can be any field on the primary business object of your report data source.

What’s available to use as a Field in other boolean conditions throughout Workday will be context-specific. For example, if you’re creating a Business Process Condition on the Hire business process, any Field you use must be available on the Hire BP (any Field on the Hire Employee Event business object is typically a safe choice here).

Recall that fields can be one of 7 main types…

The *Operator (labeled “Relational Operator” in some contexts) is the connection between your Field and its Comparison Value. It’s the instruction you provide that tells Workday how your Field should be compared to its Comparison Value. Operator also has an asterisk—it’s the only other required input in a condition.

The Operator is where boolean condition setup starts to get interesting…

The options you’re given for Operator are dependent upon your Field’s field type.

For example, an Operator of “in the selection list” wouldn’t apply to a Text field, but it will apply to a Single Instance or Multi-Instance field. An Operator of “contains (case sensitive)” wouldn’t apply to a Numeric field, but will apply to a Text field.

Here’s a table of available Operators by field type. As you learn, it’s helpful to think through why each Operator makes sense for one field type, but wouldn’t apply to another:

The Comparison Type tells Workday where your Comparison Value will come from. You’ve got two options here in most contexts. Let’s discuss them…

1️⃣ Value specified in this filter

This option tells Workday that your Comparison Value will be specified within the condition line. You’re telling Workday that you’re going to hardcode a Comparison Value into the condition. It’s specific and not very flexible. In this case, inflexibility isn’t a bad thing—it just depends on your use case.

The Comparison Type’s impact on the Comparison Value input will depend on the Field type. For example, if you select “Value specified in this filter” in a condition line where the Field is Text, in the Comparison Value, you’ll need to type in specific text. Let’s say your field is Employee ID, which is a text field. Your Comparison Value must then be text:

As another example, if the Field is a Single Instance, in the Comparison Value you’ll only be able to choose from options that are specific to the Field. Let’s say your Field is Worker Type. Your Comparison Value can only be the specific Worker Type instances associated with the Worker Type field.

See how you’ve only got two options, below?

2️⃣ Value from another field

This option swings the doors to possibility wide open! ✨ With this option, your Comparison Value can come from anywhere in Workday, as long as it’s the same field type as your Field. If you’re going to select this option, you should have an intended goal in mind—the possibilities are vast and unspecific.

Here’s an example of a good use case…

Let’s say you need to create a dynamic condition that returns TRUE if a worker’s hire date is on or after the first day of the month. You need this condition to be dynamic so it works month after month without maintenance.

With a Comparison Type of “Value specified in this filter”, Workday will ask for a static date in the Comparison Value. This won’t work for your objective!

If you use a Comparison Type of “Value from another field”, however, you can now select any date field. For our purpose, we select the dynamic WD-delivered field, “First Day of the Month”.

💫 There are two bonus Comparison Types for reports…

For conditions within a Filter or Subfilter on a report, you gain access to two additional Comparison Types that allow you to make your filter conditions prompt-able!

1️⃣ Prompt the user for the value

This Comparison Type creates a required prompt within your report. For example, let’s say you set up a Filter like this:

If you populate undefined prompt defaults on the Prompt tab of the report, you’ll get a prompt for Worker Type:

While the prompt isn’t marked as “required” by default, know that the Prompt the user for the value Comparison Type does require input for the prompt in this sense: If nothing is selected in the prompt, the report will return 0 results.

If this doesn’t work for your use case, use the other more flexible option…

2️⃣ Prompt the user for the value and ignore the filter condition if the value is blank

This Comparison Type also creates a prompt within your report. With this option, however, if no input for the prompt is provided, Workday ignores the filter condition. In the example above, workers of all Worker Types will be returned on the report if the prompt input is left empty when you run the report.

In our breakdown of Comparison Type, you probably already have a solid understanding of Comparison Value.

The Comparison Value is what you are comparing your Field to. Consider this classic line of logic:

If THIS = THAT, return TRUE; else FALSE.

THIS is your Field, and THAT is your Comparison Value!

You’ll notice there’s no asterisk on this input or on Comparison Type—they’re not always required. When you select certain Operators, the Comparison Type is no longer needed. For example, if you select the Operator, “is not blank”, no comparison is needed; both the Comparison Type and Comparison Value inputs are removed:

Depending on your Comparison Type, Comparison Values can be static or dynamic. When you select a Comparison Type of “Value from another field”, there’s a ton of room for creativity. Play around a bit, and you’ll get the hang of it!

Alright, welcome to the party! 😎 Armed with all this knowledge, you’re capable of some serious customization throughout your Workday tenant 🤩

We hope that this week’s newsletter has demystified boolean condition setup for you. It’s a powerful interface with a lot going on—which is what makes it so robust and widely applicable!

Mastery of the boolean condition setup is a BIG step toward the clean customization you need for a #wellbuiltworkday. Cheers to that! 🥂

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 🥰