Running the standard schedule import via /api/v2/wfm/schedules/import and hitting a wall with the roster updates. The payload includes shift blocks for the Sydney and Brisbane teams. Brisbane skips daylight saving entirely, but NSW flips. When the import hits that transition window, the API immediately returns a 409 with WFM_SCHEDULE_OVERLAP_DETECTED.
Checked the raw request body. The timestamps are UTC and formatted correctly. The WFM dashboard renders the shifts fine until the backend validation kicks in. ACMA compliance rules demand strict adherence tracking, so skipping the validation step isn’t an option. The error response doesn’t point to a specific agent ID, just dumps the whole batch.
{
"code": 409,
"message": "Schedule import failed due to overlapping blocks.",
"details": {
"errorType": "WFM_SCHEDULE_OVERLAP_DETECTED",
"affectedEntities": 14
}
}
Tried chunking the import down to 5 agents at a time. Same result. The timezone offsets in the tenant are set to Australia/Brisbane and Australia/Sydney. Genesys handles the conversion on the UI side, but the WFM engine seems to be snapping everything to Berlin time for the validation pass. The logs show the calculation window shifting by exactly 9 hours.
Manual entry breaks the automation pipeline completely. ACMA retention logs won’t sync if the schedule blocks are missing. The fallback script just loops the failed payload back into the queue. Doing jack all to fix the roster before the 0900 handover. Validation keeps flagging the 0600 UTC handover as a direct overlap. The shift actually starts at 1600 AEST, but the engine reads it as 0600 CET. Makes zero sense. The curl call hangs for 12 seconds before spitting out the 409. Network latency to the AU endpoint is usually fine, but WFM seems to time out on the overlap check.
curl -X POST "https://mypurecloud.com.au/api/v2/wfm/schedules/import" \
-H "Authorization: Bearer <token>" \
-H "Content-Type: application/json" \
-d @apac_shifts_payload.json
Tried swapping the payload order. Nothing. The schedule group locale is definitely set to Australia/Sydney. Maybe the WFM service is pulling the admin timezone instead of the schedule group locale.