How To Build Effective Condition Rules In Workday®

How many times has this happened to you? You receive a business requirement, such as a new approval step on the Create Position BP, but only for certain Management Levels. After building what seems like a pretty straight-forward condition rule, you begin testing and the approval doesn’t trigger. Even worse, maybe the approval always triggers, regardless of the Management Level.

When I first started in the Workday ecosystem, this was a relatively common occurrence. I could generally create any condition, eligibility, or validation rule, but it might take an iteration or two…or three…or sometimes four to nail down every field, comparison, and argument required to get exactly what I needed. After building condition rules for years, I have developed some tips and tricks to make approaching a new rule easier and more effective. Employing these tips should provide you with the confidence needed to tackle any conditional requirements.

Report Fields and Values

Before starting any new condition rule, I like to review fields and data associated with whichever business object I’m working with. Rather than choosing fields and hoping they work, the Report Fields and Values report will allow you to preview the available fields for a business object and how they pull data. In our example above, you can find an already completed Create Position event record, click the related action, and run the Report Fields and Values to see which Management Level fields are available, which ones pull data, and what that data will look like. You may find that there isn’t a delivered field to use in your condition rule, so you may need to create a calculated field or two to pull the data you need.

See my colleague Jen Kuzmick’s awesome blog post about Report Fields and Values for more information on this feature.

Searching for Fields

When searching for your desired field, Workday may return many results. If you run into the occasional search performance issues (which have become less frequent after a recent patch), you can use the search prefix of “field: field name” to quickly return results. While Workday provides an incredible search tool that allows for partial search terms, use full search terms when you know the exact name of the field you are looking for. If your search term is the exact name of a field, it will be delivered to the top of the results, which is particularly helpful for a field such as “Worker”. If you have to rely on partial search terms, continue typing after the search results have been delivered. This will jump you to fields within the search results.

Report Field Business Objects

Even after reviewing the Report Fields and Values for your Business Object, you need to be careful when choosing the correct field for your condition rule. For example, when building a condition rule for the Create Position BP you will find multiple “Management Level” fields. Clicking the related action button for each field reveals that none of these fields are associated with the Position Request Event BP. They are associated with Worker or an existing position related business object, but nothing referenceable by the Create Position BP. When choosing your fields, always click the related action button to ensure you are choosing a field associated with the correct business object. This is particularly important for common fields such as Worker, Position, or Job Profile.

Consider The Timing

The fields and values of a business process may return differently depending on when they are evaluating. For instance, some fields might not begin to populate data until after the completion step, which is why BP condition rules regularly reference “Current” or “Proposed” fields. Additionally, some fields may not begin to populate until after the successful submission of the initiation step. This can be particularly problematic for validation rules, especially when you need to consider a characteristic of the initiator. For instance, if you need a validation rule to evaluate the security groups or roles of the initiator, then your calculated fields to pull this data will need to reference “Current Worker”, as the “Initiator” field is not populated until after the exit of the initiation step.

Also consider the timing of in-flight BPs when adding new condition rules to Sub-Process BPs. For instance, if you place a new condition rule on an existing step for Onboarding, this rule will not work for any in progress Hire events. The rule would need to be tested with either a manually launched Onboarding event or with a new Hire event.

Rule Tester

Even after previewing the Report Fields and Values, carefully picking fields based on their Business Objects, and considering the timing, sometimes a condition rule will still not work on the first test. As deflating as that experience can be, Workday provides a Rule Tester than can evaluate your test scenario against your condition rule. This can help you to determine if there is a problematic field in your rule. To launch the rule tester, find your event record, click the Related Action and choose Business Process > Test Rule.

The Rule Tester always evaluates as of “now”, so if you run it at the end of a scenario, the results may be different than when the rule originally evaluated (consider the timing). If there is no logical stop in your process between the initiation and the step for your rule, you can rely on the “Save for Later” option of the initiation step. By clicking “Save for Later” a process record will be created and you can run the Rule Tester or the Report Fields and Values to evaluate the behavior of the fields in your rules.

Always Test The Negative

Occasionally, you may develop a condition rule that always evaluates as true/false, regardless of the specific data of the event or object. This can frequently occur with rules that use a “Is Not Empty” or “Is Empty” type of condition. It can be tempting to mark your scenario and condition rule as successful if they work in the positive scenario (triggering the step you intended to enter). However, you should always test at least one negative scenario. If your approval should always trigger for Management Levels 3 and above, then it should always skip for Management Levels 4 and below. Testing for the negative will help reinforce that your rule worked correctly, rather than accidentally working.

Following these tips and tricks will enable you approach condition rule development or troubleshooting with the confidence to deliver on any requirement. Good luck testing and please share any other cool tips you use to make condition rule development and testing easier.