Quick question about WFM schedule imports. Using genesyscloud wfm-schedule import with v2.14.0 on macOS 14. Payload validates locally but returns 422 Unprocessable Entity on /api/v2/wfm/schedules/import with error code WFM_SCHEDULE_INVALID_OVERLAP. JSON body attached. Terraform state shows no conflicts. Any known strictness in the overlap checker?
Check your shift definitions within the JSON payload for any hidden overlap in start/end times that might not be obvious in the local validation. The Genesys Cloud WFM engine is extremely strict about continuous time blocks. Even a single second of overlap between two shifts for the same user on the same day triggers the WFM_SCHEDULE_INVALID_OVERLAP error. This is a common bottleneck during high-volume imports where automated scripts generate schedules.
In my experience running load tests against the scheduling APIs, the issue often stems from timezone conversion errors. If your CLI is running in America/New_York but the schedule data is generated in UTC without proper offset calculation, the boundaries can shift. Ensure the start_time and end_time fields are strictly ISO 8601 format with explicit timezone offsets.
Also, verify that no two shifts for the same user share the same date range. The system does not allow partial overlaps. Here is a corrected structure that avoids the overlap flag:
{
"users": [
{
"user_id": "12345",
"shifts": [
{
"start_time": "2024-01-01T08:00:00-05:00",
"end_time": "2024-01-01T16:00:00-05:00",
"shift_type": "regular"
},
{
"start_time": "2024-01-01T16:00:00-05:00",
"end_time": "2024-01-01T23:59:59-05:00",
"shift_type": "regular"
}
]
}
]
}
Notice the end time of the first shift matches exactly the start time of the second. If there is any gap or overlap, the 422 error persists. Try adjusting the end time of the first shift to be exactly the start time of the next. This usually resolves the conflict immediately.