Can anyone clarify the correct sequence for updating genesyscloud_wfm_schedulegroup via Terraform?
Terraform v1.6.5 and Genesys Cloud Provider v1.28.0 in AP Southeast. Pipeline fails with 409 Conflict on apply. State drift suspected.
Can anyone clarify the correct sequence for updating genesyscloud_wfm_schedulegroup via Terraform?
Terraform v1.6.5 and Genesys Cloud Provider v1.28.0 in AP Southeast. Pipeline fails with 409 Conflict on apply. State drift suspected.
TL;DR: Enforce deployment order in Terraform using depends_on to ensure prerequisites are created before the schedule group.
The documentation actually says that resource dependencies must be explicitly managed to prevent race conditions during IaC execution. The 409 Conflict usually indicates that the system is attempting to link a schedule group to a resource that has not yet been fully committed in the platform state. This is not necessarily state drift, but rather a timing issue in the provider’s apply logic.
When defining the genesyscloud_wfm_schedulegroup, ensure that any referenced genesyscloud_wfm_schedulegroup_schedule or associated genesyscloud_wfm_managementunit resources are declared with explicit dependency constraints. The provider does not automatically infer these relationships for complex WFM structures.
resource "genesyscloud_wfm_schedulegroup" "main" {
name = "Production Schedule Group"
description = "Managed via IaC"
# Explicitly depend on the management unit to ensure it exists first
depends_on = [genesyscloud_wfm_managementunit.prod_unit]
}
resource "genesyscloud_wfm_managementunit" "prod_unit" {
name = "Production Unit"
}
This approach ensures the management unit is fully provisioned before the schedule group attempts to associate with it. Additionally, verify that no concurrent manual edits are occurring in the Genesys Cloud UI during the pipeline run. Manual changes can trigger optimistic locking failures that manifest as 409 errors. If the issue persists, check the genesyscloud_wfm_schedulegroup plan output to confirm that no unintended changes are being detected in the existing state. The provider version v1.28.0 has known quirks with complex WFM dependencies, so explicit ordering is the most reliable mitigation.