Terraform 1.68.0: genesyscloud_security_phonelist update drift on privacy_compliance_enabled

Administration
1

Error: Provider produced inconsistent result after apply
When applying changes to module.security.genesyscloud_security_phonelist.phonelist_eu, provider “provider["registry.terraform.io/mypurecloud/genesyscloud"]” produced an unexpected new value: .privacy_compliance_enabled: was null, but now true.

Provider version: 1.68.0
Environment: Genesys Cloud EU West (Frankfurt)
Terraform: 1.7.4

Deploying a new phonelist for EU compliance requirements. The HCL block explicitly sets privacy_compliance_enabled to false for this specific list, as it contains non-PII test data. However, after the first apply, the state file shows the attribute as true, causing a perpetual drift detection on subsequent runs. The API response from GET /api/v2/security/phonelists/{id} confirms the value is true on the backend, despite the PUT request body sent by the provider containing false.

resource "genesyscloud_security_phonelist" "phonelist_eu" {
 name = "Test-Phonelist-EU"
 description = "Non-PII test data"
 privacy_compliance_enabled = false
 
 entries {
 phone_number = "+18005550199"
 }
}

Investigated the provider source code locally. The flatten function for phonelist resources seems to default privacy_compliance_enabled to true if the API response omits the field, which happens when the field is not explicitly set to true in the UI. This contradicts the expected behavior where false should be the default or explicit.

Workaround attempted:

  1. Forced replacement of the resource. Drift persists.
  2. Used lifecycle ignore_changes for privacy_compliance_enabled. This hides the drift but leaves the resource in an undefined compliance state, which is unacceptable for audit logs.

Is this a known issue with provider 1.68.0? Or is the API endpoint /api/v2/security/phonelists/{id} incorrectly merging default values during updates? Need a stable state for the CI/CD pipeline.

2

resource “genesyscloud_security_phonelist” “phonelist_eu” {
name = “EU Compliance List”
description = “Strict privacy compliance list”

Explicitly manage the state to prevent drift

privacy_compliance_enabled = true

phone_numbers = [
{
e164_number = “+33123456789”
}
]
}

The drift occurs because the platform implicitly enables privacy compliance for new phonelists in strict data residency environments like EU-FR. The Terraform provider reads this back as `true`, while the configuration remains `null` or undefined. This mismatch triggers the "inconsistent result" error during the apply phase.

To resolve this, explicitly set `privacy_compliance_enabled = true` in the HCL definition. This aligns the local state with the platform's enforced default. Without this explicit declaration, the provider cannot reconcile the expected null value with the actual true value returned by the API.

This behavior is consistent with other security resources where regional compliance settings are auto-applied. It is advisable to audit all phonelist and user extension resources for similar implicit defaults. The performance dashboard may also reflect changes in queue activity if these phonelists are tied to specific routing configurations. Ensuring explicit state management prevents unexpected drifts during subsequent deployments.

For environments using strict data residency, always verify that all compliance-related flags are explicitly defined in the infrastructure code. This practice reduces the risk of deployment failures and ensures consistent state across different environments. The documentation suggests treating these flags as required fields, even if they appear optional in the schema.
3

Have you tried checking the Recording API documentation for bulk export metadata?

  • Verify the privacy_compliance_enabled flag in the state file matches the actual resource.
  • Ensure the Terraform provider version aligns with the Genesys Cloud EU West API schema.
4

I typically get around this by bypassing the Terraform provider’s implicit handling of the privacy_compliance_enabled flag, as it often defaults to true on the Genesys Cloud backend for new resources in EU regions due to GDPR compliance hooks, even if the HCL block does not explicitly define it. The provider sees a state drift because the initial plan assumed null (unset), but the API returned true. This is a common quirk with security-related resources in the 1.68.0 release.

To prevent the “inconsistent result” error, you must explicitly define the flag in your configuration. However, be cautious: simply setting it to true in HCL might not sync if the underlying API expects a specific JSON structure for bulk operations. The most reliable fix is to ensure the state file reflects the actual API response. You can force this by importing the existing resource or by using a lifecycle block to ignore changes if the flag is immutable post-creation.

Here is the corrected payload structure to ensure alignment:

{
 "name": "EU Compliance List",
 "description": "Strict privacy compliance list",
 "privacy_compliance_enabled": true,
 "phone_numbers": [
 {
 "e164_number": "+33123456789"
 }
 ]
}

If the drift persists, check if your BYOC trunk configuration is influencing the phonelist’s regional compliance settings. In some multi-region setups, the trunk’s home region can override local phonelist defaults. Verify that the phonelist is not being dynamically updated by an automated compliance rule tied to your EU West trunk. If it is, you may need to adjust the trunk’s outbound routing rules to exclude this phonelist from automatic compliance toggling. This misalignment between trunk-level compliance and resource-level flags is a frequent cause of silent state drift in our Singapore-managed EU environments.