Quick question about the Genesys Cloud WFM Quality Management API behavior when using Terraform.
Running into a blocking conflict during automated deployment. The genesyscloud_wfm_evaluation_rule resource fails on every apply after the initial creation. The state file shows the resource exists, but the API returns a 409 Conflict. This breaks our CI/CD pipeline for the quality module.
The environment is Genesys Cloud Australia (AU1). Using the mypurecloud/genesyscloud provider version 1.18.0. The issue appears specific to the type field set to QUALITY. When switching to ADHERENCE, the resource updates without issue. This suggests a backend constraint or a race condition in the Quality Management service layer.
The error payload indicates a duplicate key violation, yet the rule name and ID are unique in the org. No other processes are touching this resource. The Terraform plan shows no changes, but the apply still fails.
Error: 409 Conflict
Status: 409
Code: duplicate
Message: Entity with the same name already exists
Response: {"errors":[{"code":"duplicate","message":"Entity with the same name already exists","status":"409"}]}
The HCL configuration is standard:
resource "genesyscloud_wfm_evaluation_rule" "qc_rule" {
name = "QC Rule - Compliance Check"
description = "Automated compliance check rule"
type = "QUALITY"
rule_type = "SINGLE"
section {
name = "Compliance"
item {
name = "Greeting"
type = "OPTIONAL"
weight = 1
scoring_rule {
type = "RATING"
rating {
name = "Good"
value = 1
}
rating {
name = "Bad"
value = 0
}
}
}
}
}
Has anyone seen this specific 409 on WFM Evaluation Rules? Is there a workaround or a required delay in the provider? The standard depends_on logic does not resolve the conflict. The resource must be manually deleted in the UI before Terraform can recreate it, which defeats the purpose of IaC. Looking for a programmatic fix or a provider-level patch. Timezone is AEST, deployments run at 02:00 local time. No other concurrent updates are scheduled. The API logs show the request hits the WFM Quality endpoint directly. No proxy issues. The conflict seems inherent to the resource definition or the API validation logic. Any insights appreciated.