We’re experiencing an issue where our business process configured to trigger on shift template updates has stopped working after upgrading to R1 2023. The BP is supposed to send notifications to hourly employees when their shift assignments change, but notifications aren’t being delivered.
The business process configuration looks correct - event type is set to “Shift Template Change” with conditions checking for hourly worker type. When I manually test the BP it works fine, but real shift template updates aren’t triggering it at all.
This is causing major problems because hourly employees aren’t getting notified about schedule changes, and time tracking data isn’t updating as expected. Our supervisors are having to manually contact employees about shift changes which defeats the purpose of automation.
Has anyone else encountered BP triggering issues with schedule management after R1 2023 upgrade? Any ideas what could prevent the event from firing?
I can see you’re hitting the integration event triggering limitation introduced in R1 2023. Here’s what you need to do:
Root Cause: Workday R1 2023 changed how business processes handle integration-initiated events. By default, BPs no longer trigger from API/EIB operations to prevent cascading automation issues.
Solution for all three focus areas:
Enable Integration Event Triggering: Edit your business process definition and navigate to the Advanced Options section. You’ll find a new checkbox called “Allow Triggering from Integration Operations” - enable this. This addresses why shift template updates aren’t firing the BP.
Configure Event Source Filtering: In the BP event configuration, add an event source condition that explicitly includes your integration system user. Go to Business Process > Edit > Event Configuration > Event Sources and add your integration service account. This ensures hourly employees receive notifications even when changes come from automated sources.
Update Time Tracking Synchronization: After enabling integration triggering, you need to add a step in your BP that explicitly calls the “Refresh Time Tracking Data” task. This is now required because integration-initiated BPs don’t automatically trigger downstream data refreshes like UI-initiated ones do.
Additional configuration needed:
// In your integration code, add event trigger parameter:
Trigger_Business_Process=true
Business_Process_Name="Shift_Change_Notification"
Important: Test thoroughly in sandbox first. Integration-triggered BPs can create high volumes of notifications if your bulk updates affect many employees simultaneously. Consider adding a batch notification step instead of individual emails if processing more than 50 employees per update.
Also update your integration error handling to catch BP trigger failures - these won’t cause the integration to fail but you need visibility when notifications aren’t sent.
After making these changes, monitor the first few integration runs closely. Check Process History to confirm instances are being created and Notification History to verify employees are receiving shift change alerts. The time tracking data should now update automatically within 15 minutes of shift template changes.
This draft is based on general Workday knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
Have you checked the business process security? After R1 2023, there were changes to how schedule management security domains interact with BP execution. The initiating event might be firing but the BP lacks permission to complete.
Also verify your event configuration - make sure you’re using the correct event type for shift template changes versus individual shift assignments. Those are two different triggers.
Thanks for the response. I checked the security and the BP service account has all required permissions for schedule management domain. The event type is definitely set to “Shift Template Change” - I double-checked that.
One thing I noticed: when I look at the process history, there are no failed instances, which suggests the event isn’t firing at all rather than failing during execution. If it was a security issue, wouldn’t we see failed process instances?
We had something similar happen after an upgrade. The issue was that our shift template changes were being made through an integration rather than directly in Workday UI. Integration-initiated changes don’t always trigger the same events as manual changes.
Are you updating shift templates through EIB, API calls, or manual UI changes? That could explain why manual testing works but production updates don’t trigger the BP.
Tested this on our R1 2023 tenant and enabling ‘Allow Triggering from Integration Operations’ in the BP Advanced Options immediately resolved our EIB-initiated schedule management events.
That’s a really good point. We do use an integration to bulk update shift templates weekly. But this worked fine pre-upgrade. Did something change in R1 2023 regarding integration-triggered events?
Yes, R1 2023 introduced stricter event triggering rules for integration operations. By default, many business processes won’t trigger from API or EIB operations unless explicitly configured. This was done to prevent integration loops and performance issues.
Check your integration system user permissions and also look at the BP configuration itself - there should be a checkbox or setting about whether to allow triggering from integration operations.