Overview
Definitiv now supports a ELSE IF or Stop After First Success option on award rules, allowing sub-rules to be configured as mutually exclusive. When this option is enabled on a rule, the award engine stops evaluating further sub-rules as soon as one sub-rule passes successfully, preventing incorrect stacking or doubling of entitlements.
Key Benefits:
Prevents multiple sub-rules from firing simultaneously when only one outcome is intended.
Accurately models "if this, else if that" logic within a single award rule.
Reduces the risk of overpayment caused by overlapping rule conditions.
Provides a small processing performance improvement by skipping unnecessary condition evaluations.
Maintains full backward compatibility — existing rules without this option behave exactly as before.
Getting Started
Who Can Configure This Feature
For System Administrators / Award Policy Configurators:
Access to Award Policy configuration is required.
Understanding of the rule hierarchy (rules and sub-rules) within the award policy.
For Payroll Officers:
No additional permissions are required.
When configured, the stop-after-first-success behaviour is applied automatically during pay run processing.
📌 Note: This is an opt-in feature. Existing award rules and sub-rules continue to behave exactly as before unless the option is explicitly enabled on a rule.
Understanding the Problem
Default Sub-Rule Behaviour
By default, the award engine evaluates all sub-rules within a rule, regardless of whether an earlier sub-rule has already succeeded. In some award configurations, this means multiple sub-rules can fire at the same time, resulting in conditions and pay outcomes being applied in combination, even when only one was intended.
Example: Default behaviour (all sub-rules always evaluated)
Rule | Sub-Rule | Result |
Rule 1 | Sub-Rule 1.1 (shift rate) | Passes ✓ — pay applied |
Rule 1 | Sub-Rule 1.2 (on-call rate) | Also passes ✓ — pay also applied |
When only one outcome was intended, both sub-rules firing leads to incorrect double payment.
ELSE IF Behaviour
With ELSE IF enabled on the parent rule, evaluation stops as soon as one sub-rule passes. Sub-rules after the first successful one are skipped entirely.
Example: ELSE IF enabled
Rule | Sub-Rule | Result |
Rule 2 | Sub-Rule 2.1 (shift rate) | Passes ✓ — pay applied |
Rule 2 | Sub-Rule 2.2 (on-call rate) | Skipped — 2.1 already succeeded |
Behaviour When an Earlier Sub-Rule Fails
If the first sub-rule does not pass, evaluation continues to the next sub-rule. Only a successful sub-rule triggers the stop.
Example: First sub-rule fails, second succeeds
Rule | Sub-Rule | Result |
Rule 3 | Sub-Rule 3.1 (weekday rate) | Fails — condition not met |
Rule 3 | Sub-Rule 3.2 (weekend rate) | Passes ✓ — pay applied, processing stops |
Rule 3 | Sub-Rule 3.3 (public holiday rate) | Skipped — 3.2 already succeeded |
📌 Note: The ELSE IF option can be set at any level of the rule hierarchy. A nested sub-rule can have its own ELSE IF setting, independent of its parent rule.
Configuring ELSE IF condition
Enabling the Option on an Award Rule
Navigate to Payroll > Award Policies.
Select the award policy you wish to configure.
Locate the rule containing the sub-rules you want to make mutually exclusive.
Edit the parent rule and enable the ELSE IF option (see below).
Save the award policy.
⚠️ Important: This setting controls sub-rule processing on the rule it is applied to. It does not affect the rule itself, only how its child sub-rules are evaluated.
Sub-Rule Order Matters
Because processing stops at the first successful sub-rule, the order in which sub-rules are arranged is significant. Place the most specific or highest-priority conditions first to ensure the correct sub-rule fires.
Place more specific conditions (e.g. public holiday with overtime) before less specific ones (e.g. ordinary public holiday rate).
Place the most common expected condition earlier if performance is a consideration.
Use Cases
When to Use This Feature
This feature is suited to scenarios where a set of conditions are alternatives — only one should ever apply at a time. Common examples include:
Shift type classification (e.g. day shift, afternoon shift, night shift — only one applies per shift, and the conditions are a mix of start and finish times)
Public holiday entitlement tiers (e.g. worked / not worked / worked with overtime, mutually exclusive outcomes)
Penalty rate bands where ranges are defined as distinct brackets
When Not to Use This Feature
Do not enable this option where multiple sub-rules are intentionally designed to fire together and each adds an independent component to the pay outcome. This includes:
Sub-rules that apply separate allowances, which should always accumulate.
Rules where all matching conditions should be applied (e.g. multiple applicable penalty rates that are genuinely additive)
How Pay Runs Apply This Feature
Once configured, the ELSE IF behaviour is applied automatically during pay run processing. No additional steps are required by the payroll officer.
During pay run calculation:
The award engine evaluates sub-rules in the configured sequence.
For rules with ELSE IF enabled, processing halts as soon as one sub-rule passes.
Subsequent sub-rules within that rule are not evaluated.
Pay is calculated based on the single successful sub-rule outcome.
Backward Compatibility
This feature does not change the behaviour of any existing award rules. Rules without the ELSE IF option enabled continue to evaluate all sub-rules as they always have. There is no risk of backpay or unintended rate changes from enabling this option on new or newly versioned rules.
Important: It is recommended that when adding this option to an existing award, create a new version of the award (ending the current version at a pay period boundary and starting the new version at the next) to ensure a clean audit trail and to avoid mid-period calculation changes.
Troubleshooting
Sub-Rule Not Firing When Expected
Problem: A sub-rule that should apply is being skipped
Solution:
Check whether ELSE IF is enabled on the parent rule.
Review sub-rule ordering — an earlier sub-rule may be matching first.
Tighten the conditions on the earlier sub-rules so they only fire for their intended scenarios.
Multiple Sub-Rules Still Firing
Problem: More than one sub-rule is applying when only one was expected
Solution:
Confirm the ELSE IF option is saved and published on the correct parent rule.
Verify the award policy version in use during the pay run is the updated version.
Check that the sub-rules in question belong to the same parent rule where the option is enabled.
Frequently Asked Questions
Q: Does this affect all rules in the award automatically?
A: No. ELSE IF must be enabled individually on each rule where mutually exclusive sub-rule behaviour is required.
Q: What happens if no sub-rules pass?
A: The parent rule simply does not produce a result for that evaluation. This is the same as the current default behaviour when no sub-rules pass.
Q: Can I nest this option within sub-rules?
A: Yes. ELSE IF can be set at any level of the rule hierarchy. A nested rule (sub-rule of a sub-rule) can have its own independent setting.
Q: Will enabling this option cause a backpay event?
A: This is a new option with no risk of triggering backpay. It simply prevents additional sub-rules from being evaluated once one succeeds. It does not change rate values.
Q: Do I need to republish my award policy after enabling this option?
A: Yes. Award policy changes take effect only after the policy is saved and published. Ensure the updated policy is in effect for the relevant pay period.
Getting Help
Review this guide for configuration and troubleshooting information.
Contact your system administrator for award policy configuration questions.
Contact support if you need assistance with rule configuration or pay run outcomes.
Summary
ELSE IF makes sub-rules within a rule mutually exclusive.
The award engine stops evaluating sub-rules as soon as one passes.
Sub-rule order determines which condition is evaluated first; order carefully.
Existing rules without this option are unaffected.
This option can be applied at any level of the rule hierarchy.
No backpay risk is associated with enabling this option.