Creating and Editing Notice Period Eligibility Rules in Workday: A Step-by-Step Guide

What notice period eligibility rules actually do in Workday

If you've spent any time in Workday's termination configuration, you've probably run into notice period eligibility rules — and wondered why changing something that sounds simple takes as long as it does. The short version is that Workday uses rule-based logic to determine which employees are subject to notice period requirements, and when those rules are wrong or incomplete, the downstream effects show up in offboarding workflows, payroll calculations, and compliance reporting.

Notice period eligibility rules define which workers fall under a specific notice period policy. They sit in Workday's business process framework and typically evaluate a combination of employee type, location, job profile, union membership, and time in role. When a termination event is initiated, Workday checks these rules to determine what notice obligations apply — either for the organization or the employee. Getting this configuration right isn't just a matter of administrative tidiness. It directly affects how offboarding plays out in practice and whether your payroll team ends up manually correcting payments after the fact. Understanding this is part of the broader cost-benefit reality of investing in a modern HRMS — the system is only as useful as the configuration behind it.

Before you start: what you need in place

Creating or editing these rules without the right prerequisites in place tends to produce frustrating results. Workday will let you save configurations that don't work the way you expect, and the errors often only surface during actual termination processing.

A few things you need before touching this configuration. First, make sure your notice period policies are already created in Workday — you can't assign a rule to a policy that doesn't exist yet. Go to Maintain Notice Periods (the task is called "Maintain Notice Periods" in the search bar) and confirm your policies are there, correctly named, and attached to the right eligibility rules.

Second, you need the right security role. Notice period configuration lives in the HR Partner or Benefits Partner functional area. If you can see the Maintain Notice Period Eligibility Rules task but can't save changes, a security permission is missing — your Workday admin will need to add the correct domain security policy access. This is a common sticking point that gets overlooked until the first save attempt fails.

Third, know your condition fields. The rule logic uses Workday condition fields, which are pre-defined attributes you can combine with operators (equals, is in, etc.). Before building a rule, identify exactly which employee segments you're targeting — job classification, company, country, employee type. Trying to figure this out after you're inside the rule configuration editor adds unnecessary complexity to what's already a somewhat unintuitive interface.

Creating a new notice period eligibility rule

Navigate to the Create Eligibility Rule task in Workday. You can find it by typing "Create Eligibility Rule" in the search bar — it will appear under the HR worklet. If it doesn't appear, your security role doesn't include access to this task.

The first field asks for a rule name. Use a naming convention that includes the employee population and the country or region — something like "Permanent Employees — United Kingdom" or "Salaried Exempt — California." Generic names like "Notice Period Rule 1" become a maintenance problem six months later when you need to figure out which rule applies to which population.

The eligibility criteria section is where most of the configuration work happens. You're building a condition set that defines which employees this rule applies to. Click "Add" to add a condition, then select the field, operator, and value. Common fields include Worker Type, Company, Country, Job Classification Group, and Time in Position.

A few practical notes on building conditions. The "Is In" operator is almost always more useful than "Equals" when you're targeting multiple values — for example, if the rule should apply across several legal entities. The order of conditions matters for readability but not for logic evaluation; Workday evaluates all conditions as AND by default (all must be true). If you need OR logic — for example, a rule that applies to both regular and fixed-term employees in a given country — you'll need to create separate rules or use a condition category that combines them. This kind of layered logic is what makes notice period rules feel more complex than they should be, and it's worth spending time on building HR configuration skills systematically rather than learning it piecemeal through trial and error.

Once your conditions are set, scroll down to the Notice Period section. This is where you associate the rule with the actual notice period policy. Select the policy from the dropdown, set whether the notice period applies to the employer, the employee, or both, and specify the notice type (calendar days vs. working days if your configuration supports it). Click OK to save the rule.

Editing an existing rule

The Edit Eligibility Rule task works similarly to creation, but with a few nuances worth knowing. First, find the rule using the Maintain Notice Period Eligibility Rules task — not by searching for the rule name directly. The search results from a direct search sometimes return the rule object but not in an editable state.

Once you're in the rule, you can add, remove, or modify individual conditions. Be careful about removing conditions on rules that are actively being evaluated. If a rule is currently referenced in a live termination business process, editing it takes effect immediately for any new terminations initiated after the save. Terminations already in progress will use the rule as it was when they were initiated.

One situation that comes up regularly: a rule that was correct when it was created no longer matches the employee population because Workday tenant data has changed — job classifications were reorganized, new legal entities were added, or country configurations shifted. In these cases, the rule's conditions reference values that either no longer exist or no longer mean what they did. Before editing, pull a list of current employees who would match the rule as-is, and compare it to the target population. Workday's "Preview Eligibility" functionality (where available in your tenant version) can help with this. It's the kind of configuration audit work that tends to get skipped until something breaks — the same principle that applies when organizations evaluate their automation implementations with a structured checklist rather than assuming everything is still running as intended.

When editing conditions, use the edit icon next to each existing condition rather than deleting and re-adding. Deleting a condition and recreating it with slightly different values sometimes produces different behavior than editing in place, particularly around how Workday caches condition field values.

Testing your configuration

Saving a rule doesn't mean it works correctly. The only reliable way to confirm the configuration is to test it against real employee data before it matters.

Create a test termination for an employee in each population the rule is supposed to cover, and verify that Workday presents the correct notice period in the termination business process. If you don't see a notice period presented, either the rule isn't matching the employee or the rule isn't connected to the right business process step. Check the business process definition to confirm the notice period step is included and that the correct eligibility rules are mapped to it.

Also test the negative case — employees who should not be subject to the rule. Initiate a test termination for someone outside the target population and confirm that no notice period (or a different notice period) is presented. Eligibility rule errors often show up as rules being too broad and catching populations they weren't intended to cover, rather than being too narrow. This kind of systematic testing is what separates a reliable configuration from one that creates exceptions every time someone in an edge case is terminated. It connects to how well-designed decision support systems are built — the logic only works when it's been validated against real scenarios, not just theoretical ones.

Document your test results. If you need to audit the configuration later or demonstrate compliance, having a record of what was tested and when is more useful than relying on memory.

Common problems and how to fix them

A few issues come up repeatedly in notice period eligibility rule configuration.

The rule saves but doesn't appear in termination: This almost always means the rule isn't attached to the right termination business process step. Go to the business process definition for Terminate Employee, find the notice period step, and confirm the rule is listed there. If it isn't, add it. If the step doesn't exist, it may need to be added to the business process by your Workday admin.

Multiple rules are matching the same employee: Workday will present whichever rule has the highest priority if you've configured priorities, or display an error if priority hasn't been set. Review all active rules and look for overlap in the condition criteria. Clean up overlapping rules before they cause processing errors in live terminations.

Notice period shows as zero days despite an active rule: Check that the notice period policy itself has a duration configured, not just a name. A policy with a blank duration field will display as zero even when the eligibility rule correctly matches. This is easy to miss when policies are copied from a template without filling in all fields.

The editing user can't save changes: As noted above, this is a security configuration issue. The user needs domain security policy access to the relevant HR functional area. Raise it with your Workday security administrator rather than trying to work around it. This kind of gap between what an HR team needs to do and what the system allows them to do is a recurring theme in HR technology — the same gap that creates downstream talent management problems when it goes unaddressed.

Keeping rules current over time

Notice period eligibility rules aren't a configure-once-and-forget item. Employment law changes, organizational restructuring, and Workday tenant updates all create reasons to revisit configurations. Building a regular review cycle into your HR operations calendar — at minimum annual, more frequently if your organization operates across multiple jurisdictions — catches drift before it causes compliance problems.

The organizations that manage this well tend to treat their Workday configuration as an asset that requires maintenance, not a project that gets delivered and handed off. The same mindset that applies to keeping compensation and benefits systems accurate and fair applies here — the configuration reflects real-world policies, and when those policies change, the system needs to change with them. A rule that was perfectly accurate eighteen months ago may now be covering a population it shouldn't, or missing a population it should. Building in the process to check periodically is the difference between a Workday configuration that works and one that quietly accumulates exceptions until an audit or a termination dispute forces a cleanup.