We run a massive contact center covering the entire APAC region out of our Sydney hub! I’ve run into a weird edge case with the ‘Evaluate Schedule Group’ block in Architect.
During the recent Daylight Saving Time transition in Australia, we noticed that callers dialing our toll-free number from New Zealand were being routed to our ‘Out of Hours’ flow for an entire hour before our actual close time. The Schedule Group is strictly set to ‘Australia/Sydney’ timezone. It seems Architect might be trying to evaluate the caller’s local time (derived from the ANI) instead of just honoring the absolute time of the schedule group itself. Is there a way to force Architect to strictly evaluate against the server’s UTC time rather than attempting to localize?
I’ve filed a bug on the Genesys GitHub regarding date-time parsing before, and this sounds similar.
Architect shouldn’t use the ANI to determine the time zone of the schedule group evaluation. However, there is a known issue when using the GetCurrentDateTimeUtc() function within expressions before passing the result into a Schedule Group block, especially if your flow’s ‘Default Time Zone’ setting conflicts with the Schedule Group’s explicit time zone.
Ensure that in your Architect Flow Settings, the ‘Default Time Zone’ matches ‘Australia/Sydney’, and avoid manually converting Flow.StartDateTimeUtc if you are using it in custom ‘If’ logic alongside the schedule block.
We bypass the native Schedule blocks entirely for this exact reason when building our custom desktop routing.
The native block is a black box. Instead, we use a Data Action that queries a central timezone API (or a serverless function) passing the Flow.StartDateTimeUtc. It returns a simple boolean IsOpen: true/false based on our custom logic that handles all the APAC DST nuances perfectly. It’s more work, but you get total control over the timezone arithmetic.