Encountering a persistent integration failure when publishing the weekly schedule for the Chicago workforce (America/Chicago timezone) via the Genesys Cloud WFM module.
The specific issue occurs when the POST /api/v2/wfm/scheduling/schedules/{scheduleId}/publish endpoint triggers a downstream webhook to our BYOC trunk registration service.
While the WFM API initially returns a 200 OK, the subsequent HTTP request task in Architect times out after exactly 30 seconds, resulting in a 504 Gateway Timeout for the external system.
Our BYOC provider requires approximately 45 seconds to validate and register the new agent availability states derived from the published schedule.
The Architect flow is configured with the default timeout settings, which appears to be the bottleneck preventing successful trunk registration for agents involved in shift swaps.
Error logs in the BYOC provider’s dashboard show Connection Reset by Peer at the 30-second mark, coinciding with the Architect flow termination.
We have verified that the schedule data itself is valid and that agent preferences for shift trades are correctly processed before the publish event.
The problem is isolated to the weekly publish event; ad-hoc schedule adjustments do not trigger this specific webhook timeout.
Attempted to increase the timeout in the Architect HTTP request task, but the UI restricts the maximum value to 30 seconds for standard flows.
Looking for a workaround to extend the timeout duration or an alternative method to trigger the BYOC registration asynchronously after the schedule publish completes.
Current environment: Genesys Cloud Private Cloud v2023.4, Architect version 2.1, BYOC trunk using SIP trunking protocol.
This issue is blocking the accurate reflection of agent availability in the IVR routing logic, leading to increased abandoned calls during shift transition periods.