Looking for advice on handling persistent state drift with genesyscloud_wfm_evaluation_form custom attributes.
Context:
Provider: genesyscloud/genesyscloud v1.9.4
Region: au-1
Environment: Production WFM configuration via GitHub Actions CI/CD.
We are managing WFM evaluation forms entirely through Terraform. Recently, we added a set of custom attributes to an existing evaluation form to capture specific quality metrics. The initial apply succeeds, and the attributes appear correctly in the Genesys Cloud UI.
However, subsequent terraform plan executions report a perpetual drift on the custom_attributes block. The plan indicates that the remote state has different values than the configuration, even though the UI matches the HCL definitions. A terraform refresh does not resolve this. The diff typically shows the attribute order changing or minor timestamp discrepancies in the underlying JSON structure that the provider fails to normalize.
Here is the simplified resource block:
resource "genesyscloud_wfm_evaluation_form" "quality_form" {
name = "Standard QA Form"
description = "Standard quality assurance evaluation form"
custom_attributes {
name = "agent_tone"
type = "text"
label = "Agent Tone"
description = "Overall tone of the agent"
}
custom_attributes {
name = "compliance_check"
type = "boolean"
label = "Compliance Met?"
description = "Did the agent meet compliance requirements?"
}
}
The error in the plan output suggests that the id field within the custom attribute objects is being treated as volatile, even though it is generated by the platform. We suspect this is related to how the provider handles list ordering for nested attributes.
Question:
Is there a known workaround for this drift behavior in v1.9.4? Should we be using dynamic blocks with specific sort keys, or is there a provider argument to ignore specific sub-fields? We want to avoid using lifecycle { ignore_changes } if possible, as it masks real configuration errors. Any insights on stabilizing this state would be appreciated.