Custom event rule in benefits-admin module not triggering after status change

ERP Workday
, , , , , , ,
1

We’ve configured a custom event rule in our benefits-admin module to trigger notifications when an employee’s benefit enrollment status changes from ‘Pending’ to ‘Active’. The rule was working fine initially during testing, but after our latest deployment it stopped firing completely.

The event rule configuration looks correct - we’ve mapped it to the business event ‘Benefit_Enrollment_Status_Change’ and set the condition to check for status transitions. The status change logic itself works (we can see statuses updating in the UI), but the downstream notifications and automated tasks aren’t triggering.


Event Rule: Benefits_Enrollment_Notification
Business Event: Benefit_Enrollment_Status_Change
Condition: status = 'Active' AND previous_status = 'Pending'
Action: Send_Notification_Task

We’ve verified the business process configuration and the event subscription is active. Has anyone experienced similar issues with event rules not firing after status changes? This is impacting our benefits compliance timelines as managers aren’t getting enrollment confirmations.

2

Thanks for the suggestions. I checked both - the business process definition hasn’t changed and the event subscription shows as Active. However, I noticed something odd in the event subscription details. The rule is listed but when I drill into the condition logic, the field references look off. It’s referencing ‘Enrollment.Status’ but I think it should be ‘Benefit_Enrollment.Current_Status’ based on the object model. Could this be a field mapping issue?

3

Another thing - check if your condition is using the right comparison operator. I’ve debugged similar issues where the rule used ‘=’ instead of ‘changes to’ for status transitions. The ‘changes to’ operator is specifically designed for state transitions and will only fire when the value actually changes, whereas ‘=’ just checks the current value which might not trigger the event properly in all scenarios.

4

That’s likely your problem right there. Field references in event rules are very sensitive to the exact data model path. If you’re using a generic ‘Status’ field instead of the specific business object field path, the rule condition will evaluate to false every time even though the status change actually occurs. You need to use the fully qualified field reference that matches your business process configuration.

5

Also worth checking the event subscription status in your tenant. Sometimes after deployments, subscriptions get disabled accidentally. Navigate to System > Setup > Event Subscriptions and filter for your Benefits_Enrollment_Status_Change event. Make sure it shows as ‘Active’ and that your custom event rule is still listed as a subscriber. We had a similar issue last quarter where the subscription was active but the rule itself had been orphaned from the subscription list after a configuration import.

6

I ran into this exact scenario three months ago. Here’s what you need to verify:

For your event rule configuration, the field references must match the exact business object structure. When you’re working with benefits enrollment status changes, you need to reference the complete path through the Benefit Enrollment object hierarchy.

Your business event mapping needs to be checked against the actual business process step where the status change occurs. Open your Benefits Enrollment business process in Workday Studio, navigate to the specific step where status transitions from Pending to Active, and verify that the business event is published at that exact step with the correct event parameters.

For the status change logic, replace your current condition with the ‘changes to’ operator instead of equality checks:


Condition: Benefit_Enrollment.Enrollment_Status changes to 'Active'
Previous Value Filter: 'Pending'

This ensures the rule only fires on actual state transitions, not just when querying records that happen to have Active status.

Also critical - check your Event Subscription configuration. Go to System > Setup > Event Subscriptions, find your event, and click ‘Edit Event Subscription’. Verify that:

  1. The subscription is Active
  2. Your custom event rule appears in the ‘Subscribed Event Rules’ section
  3. The ‘Event Rule Parameters’ section shows the correct field mappings from the business event to your rule conditions
  4. The ‘Event Publication’ settings haven’t been modified to exclude certain status changes

If the field mappings in the subscription don’t align with what your rule expects, you’ll need to either update the event rule to match the available event parameters, or modify the business process to publish additional data fields with the event.

One more thing - after making these changes, you may need to manually trigger a status change in a test environment to force the event subscription to refresh. Sometimes the subscription cache needs to be cleared before it picks up the corrected configuration.

This should resolve your benefits compliance notification issues. The key is ensuring alignment across all three layers: business process event publication, event subscription field mapping, and event rule condition logic.

7

I’ve seen this behavior before. First thing to check - did your deployment include any changes to the underlying business process definition? Even minor BP changes can break event subscriptions if the event signature changed. Go to Configure Business Process and verify the event is still published at the correct step.