Workday Custom Validations: Blocking Bad Data at Business Process Entry

Workday provides two primary mechanisms to block bad data before a transaction commits: Validation Conditions configured via Business Process > Maintain Step Conditions on business process Initiation and Action steps, and transaction-level Custom Validations configured via Maintain Custom Validations (or domain-specific tasks like Maintain Payroll Costing Validations and Configure Custom Object Validations). In both mechanisms, you write a boolean condition rule that describes the invalid state: when the condition rule evaluates to True, Workday triggers the validation message and either blocks submission (Critical severity) or displays a dismissible alert (Warning severity).

Where to configure validations in Workday

Depending on the functional area and transaction type, Workday separates step-level workflow validations from centralized object/transaction validations:

Configuring Validation Conditions on Business Process steps

Unlike Entry Conditions (which decide whether a step executes or is skipped), a Validation Condition runs when a user clicks Submit (or Approve and Send to Approvers) on an Initiation step or an Action step.

Prerequisites for Initiation and Action step validations

1. The step must support revision (Send Back): Workday only allows validation conditions on Initiation and Action steps when the underlying Workday-delivered business process or step supports revision. To verify eligibility, run the Business Process Configuration Options report:
   • If the Approval Options column includes Send Back, you can attach validation conditions to the Initiation step.
   • If the Options on Save column under Allowed Actions includes Send Back, you can attach validation conditions to that Action step.
2. Subprocess Action steps: If an Action step launches a subprocess (for example, Propose Compensation Hire inside Hire), you attach the validation condition to the Initiation step of the child subprocess definition, or directly to the Action step via Business Process > Maintain Step Conditions.
3. Template-based business processes: For business processes that use defined templates (such as Change Job), any role with permission to initiate the business process must also have View All permission on the business process security policy so Workday can evaluate the validation conditions at runtime.

Step-by-step configuration on a Business Process step

1. Open the business process definition via Business Process > View Definition (you cannot maintain step conditions from the Edit Business Process Definition page).
2. On the Business Process Steps tab, open the related actions menu next to the magnifying glass on step a (Initiation) or the target Action step and select Business Process > Create Condition Rule.
3. Enter a descriptive Description—for step validation conditions, Workday displays the condition rule's description directly to the user as the error or warning banner.
4. Define the Rule Conditions grid so that the rule returns True when the data is invalid (for example, Comments is empty, or Proposed Base Pay Increase Percent greater than 20%). Click OK.
5. From the same step's related actions, select Business Process > Maintain Step Conditions.
6. Choose the Effective Date (defaults to today; respected for events initiated on or after that date in the configured time zone) and click OK.
7. Under the Validation Conditions grid, click Add Row, select your condition rule in the Rule prompt, and set the Severity:
   • Critical (default): When any rule in the validation condition evaluates to True, Workday blocks the step from exiting. The user cannot submit the transaction until they fix the offending data.
   • Warning: When any rule evaluates to True, Workday displays the warning banner upon submission, but allows the user to submit again to proceed to the next step.
8. Optional for Action steps: Select Enable Validation Conditions for Add Approvers if you want Workday to evaluate the step's validation conditions when a reviewer clicks Add Approvers and Approve and Send to Approvers (requires a security group on the Ad Hoc Approve action on the business process security policy).

Configuring Maintain Custom Validations for Financials, Costing, and Payroll

For financial documents, worktag combinations, costing allocations, and payroll inputs, use Maintain Custom Validations (or Maintain Payroll Costing Validations) instead of business process step conditions:

1. Run Maintain Custom Validations and select the target transaction type (such as Expense Report, Accounting Journal, Supplier Invoice, Budget Line, Payroll Input, or On Demand Payments).
2. Click New Validation under either Critical or Warning severity.
3. Populate the Description (the default error text shown to users), an internal Comment explaining the business requirement, and an optional Category (created via Maintain Condition Rule Categories).
4. In the Rule Conditions grid, combine fields using And / Or and parentheses ( ) to establish operator precedence—for example, requiring Region: North America whenever Cost Center: 10000 Office of CEO is selected on a costing allocation:
   • Line 1: Costing Allocation Proposed Organizations | any in selection list | Value specified in this filter | Cost Center: 10000 Office of CEO
   • Line 2 (And): Costing Allocation Proposed Organizations | none in the selection list | Value specified in this filter | Region: North America
5. Dynamic validation messages: In financial Maintain Custom Validations, select Validation > Configure Validation Message from the validation's related actions to combine static text with dynamic External Field values (such as report fields or calculated fields, e.g., Airfare exceeds $600 (USD) for Expense Report: [Expense Report]).

Payroll recalculation note: Before adding a new Critical rule in Maintain Custom Validations for Payroll Input or On Demand Payments, ensure all in-progress pay calculations (including off-cycle runs) are completed, because a new rule without an exception condition can block payroll recalculation.

Writing Invertible Condition Rule Logic (Avoiding False Blocks)

The most common mistake when building Workday validations is writing condition logic for what valid data looks like instead of what invalid data looks like:

• Entry Condition mindset: Rule = True means "Run this step."
• Validation Condition mindset: Rule = True means "Raise the error/warning." When all validation condition rules evaluate to False, the step exits cleanly.

Performance and evaluation order

Workday short-circuits condition rule evaluation from top to bottom:

• In a block of And statements, Workday stops evaluating the remaining rows as soon as one row returns False.
• In a block of Or statements, Workday stops evaluating as soon as one row returns True.
• Optimization rule: Place the most selective, fastest-evaluating check (such as Country in the selection list United States or Reason equal to Promotion) on the first row of an And block, and place complex multi-level calculated fields on the bottom rows so Workday only computes them when the fast filter matches.

Troubleshooting: Why a validation rule didn't fire or blocked valid entries

When a custom validation fails to trigger on bad data or unexpectedly blocks a valid submission, run through these diagnostic checks:

1. Inspect runtime field values with Report Fields and Values:
   • Open the business process event (or save the in-progress step for later), open the step's related actions, and select Reporting > Report Fields and Values.
   • Check the exact value of every field referenced in your condition rule at the moment the step executed.
   • Pre-Hire vs. Worker trap: On an in-progress Hire event prior to the completion step, the candidate is still a pre-hire rather than an active Worker. Condition rules referencing Worker-level report fields often return blank/empty until completion; use Action Event or Proposed fields instead.
2. Trace boolean evaluation with Rule Tester:
   • From the related actions menu of the business process event, run the Rule Tester report (available for customer-created condition rules) to view the line-by-line execution flow and see which specific row returned True or False.
   • On financial Maintain Custom Validations, click the Test Validations button and supply an existing transaction instance to verify both the boolean result and the execution time in milliseconds.
3. Check EIB / Web Service auto-complete bypass:
   • Workday does not evaluate business process step conditions when a business process is triggered via a web service or EIB with Automatically Complete enabled, nor do Workday Web Services enforce Configure Custom Object Validations on data uploaded via Workday Studio or delivered integrations.
4. Verify Initiator field and field-level security:
   • Do not use the Initiator source field on an Initiation step condition rule; before Workday initiates the event, Initiator returns empty.
   • While Workday generally bypasses domain security on report fields inside condition rules, if security logic is embedded inside the report field definition itself, the processing user must pass that security check or the condition fails to return data.
5. Check effective date and in-progress events:
   • Removing or editing a step condition rule via Maintain Step Conditions only affects events initiated on or after the specified effective date. Events already in progress continue to evaluate the rule version that was active when they started.

How kiweely fits

Writing condition rules and custom validations often fails because of subtle mismatches between Current and Proposed event fields, inverted And/Or parentheses, or calculated fields built on the wrong business object. kiweely connects to your Workday tenant to inspect available business object fields on the target business process step, draft and trace calculated fields and condition rules, and validate edge cases before you attach a Critical blocker to production workflows. Kiweely Personal is free for your Workday personal developer account and its tenant. Any other tenant needs a Personal licence, $99 a month, or a seat in your firm.

Frequently asked questions

Why does my validation rule trigger on valid transactions instead of invalid ones?

Workday triggers a validation error or warning whenever the attached condition rule evaluates to True. If you wrote the rule to describe valid data (for example, Cost Center is not empty), Workday blocks every transaction that has a cost center. Invert the relational operator (Cost Center is empty) so the rule only returns True when the entry is invalid.

Why can't I see Maintain Step Conditions when editing a business process definition?

You cannot access Maintain Step Conditions while inside the Edit Business Process Definition task. First save or exit edit mode, view the business process via Business Process > View Definition, and then open the related actions menu on the specific step to select Business Process > Maintain Step Conditions.

Do custom validations run on EIB loads and Workday Studio integrations?

It depends on the validation type. Business process step conditions are skipped when an EIB or web service runs with auto-complete, and Configure Custom Object Validations are not enforced on Workday Studio or delivered integration loads. However, object-level validations in financial Maintain Custom Validations (such as Accounting Journal custom validations) do run during web service imports and can impact import performance if overly complex.

How do I unblock a Budget Plan or in-progress event stuck on a deleted Critical validation?

On certain transactions like Submit Plan for Budgets, simply deleting the Critical validation in Maintain Custom Validations does not clear the cached validation state on the existing line. Replace the Critical validation with a temporary Warning validation, re-save the budget line via Plan Period > Maintain Budget so Workday re-evaluates it as a warning, submit the plan, and then remove the temporary Warning rule.