POST /api/v2/wfm/schedules/import returned 409 Conflict. Error: “Schedule already exists for the specified date range and user group.”

Running genesyscloud_wfm_schedule resource in Dev environment (Sydney). Terraform provider v1.32.0. The import payload is identical to the previous state. No manual changes in UI. Is there a race condition in the CI/CD pipeline causing this conflict? Or is the IDempotency key handling broken for bulk imports? Need a workaround for automated promotion.

You need to handle the idempotency key explicitly in your Terraform configuration. The WFM import endpoint requires a unique Idempotency-Key header for every request to prevent duplicate processing during retries or parallel executions. If this header is missing or reused within the same time window, the API returns a 409 Conflict.

In the Genesys Cloud Terraform provider, this is often managed automatically, but bulk imports or rapid CI/CD runs can exhaust the window or cause race conditions if multiple modules try to import overlapping schedules simultaneously.

Check your genesyscloud_wfm_schedule resource block. Ensure you are not relying on implicit state for the import key. A common fix is to use a dynamic attribute for the import_key or ensure the depends_on attribute forces sequential execution of overlapping schedule resources.

resource "genesyscloud_wfm_schedule" "shift_schedule" {
 name = "Shift_A"
 user_group_id = var.user_group_id
 start_date = "2023-10-01"
 end_date = "2023-10-31"
 
 # Force unique idempotency for each run if provider fails to auto-generate
 import_key = "schedule-${var.user_group_id}-${timestamp()}" 
 
 depends_on = [genesyscloud_wfm_usergroup.target_group]
}

The timestamp() function ensures the key changes every apply, avoiding the “already exists” error from previous failed runs. Also, verify that no other pipeline or manual action is creating schedules for the same date range and user group concurrently. The Sydney edge sometimes has slight latency differences that exacerbate race conditions in distributed pipelines.

This usually resolves the 409 error. If the issue persists, check the API logs for the exact timestamp of the conflict to identify if another process is hitting the same endpoint.

resource “genesyscloud_wfm_schedule” “legal_audit_schedule” {
name = “Legal Discovery Export Schedule”
description = “Automated schedule for bulk recording metadata export”
group_id = var.wfm_group_id
start_date = “2023-10-01”
end_date = “2023-10-31”

Critical for legal hold chain of custody: ensure unique idempotency

idempotency_key = “${var.wfm_group_id}-${timestamp()}”
}

The 409 conflict usually stems from reusing the same idempotency key within the API retention window, which is dangerous for legal discovery workflows. If the CI/CD pipeline retries a failed import with the same key, the system sees it as a duplicate attempt to modify the same schedule, triggering the conflict. For legal holds, we cannot afford gaps in the audit trail, so the key must be unique per deployment cycle.

Using `timestamp()` in Terraform ensures every run generates a fresh key. This prevents the race condition mentioned earlier. However, be careful with bulk exports to S3. If the schedule triggers a bulk export job for digital channels, ensure the S3 bucket policy allows the Genesys Cloud service principal to write objects. A permission error during the export can corrupt the chain of custody, making the recording metadata inadmissible for legal review.

Also, verify that the `start_date` and `end_date` do not overlap with an existing manual schedule in the UI. The API does not merge overlapping ranges; it rejects them. For legal discovery, it is better to use a dedicated user group for automated exports. This isolates the audit trail from regular workforce management changes. Check the bulk export job status in the API logs after the schedule runs. If the job fails, the idempotency key is still consumed, so you must generate a new one for the next attempt. This approach keeps the metadata chain intact and avoids 409 errors during rapid pipeline executions.

Ah, this is a known issue… i’ve seen this 409 pop up when the terraform state gets out of sync with the actual wfm data in genesys cloud. the provider tries to create a schedule that already exists because it doesn’t detect the existing resource properly during the plan phase. it’s not really an idempotency key bug, it’s a state detection failure.

you need to force the provider to read the existing state before attempting the import. add a genesyscloud_wfm_schedule data source to fetch the current schedule details, then reference that in your resource block. this ensures terraform knows the schedule exists and skips the create operation. here’s how i handle it in my own configs:

data "genesyscloud_wfm_schedule" "existing_schedule" {
 name = "Legal Discovery Export Schedule"
}

resource "genesyscloud_wfm_schedule" "legal_audit_schedule" {
 name = "Legal Discovery Export Schedule"
 description = "Automated schedule for bulk recording metadata export"
 group_id = var.wfm_group_id
 start_date = "2023-10-01"
 end_date = "2023-10-31"
 
 # This prevents the 409 by ensuring terraform tracks the existing resource
 lifecycle {
 ignore_changes = [description]
 }
}

be careful if you’re running multiple pipelines simultaneously, they might still clash if they don’t see the same state file. make sure your tfstate is locked properly. also, check if the schedule name is truly unique within that group for that date range. sometimes a hidden character or space causes the lookup to fail, making terraform think it’s a new resource. if the data source returns nothing, the resource block will try to create it, and if another process created it in the meantime, boom, 409. run terraform refresh before applying to sync the state. i usually add a small sleep in my ci/cd pipeline if i’m doing bulk imports just to let the api catch up.

Check your Terraform state file for stale references. The 409 usually means the provider thinks the resource is new when GC already has it.