Importing Genesys Cloud Routing Queues into Terraform State with Custom Attributes

General Discussion
1

migrating our routing infrastructure to the CX-as-Code Terraform provider. While we have successfully managed user and division resources, we are encountering persistent issues when attempting to import existing routing queues that contain custom attributes. The standard import command appears to handle the basic configuration, but it seems to ignore or fail to reconcile the custom attributes defined in the API response.

We have executed the import command for a specific queue:

terraform import genesyscloud_routing_queue.support_queue 12345678-1234-1234-1234-1234567890ab

The state file is updated with the resource ID, and a subsequent terraform plan shows no changes for standard fields like name or description. However, the custom attributes remain out of sync. When we inspect the state, the custom_attributes block is either empty or contains stale data from the initial plan, despite the API endpoint /api/v2/routing/queues/12345678-1234-1234-1234-1234567890ab returning the correct key-value pairs.

We have verified the following steps:

  • The Genesys Cloud provider version is 1.35.0.
  • The queue exists in the Genesys Cloud environment with three custom attributes.
  • The Terraform configuration file includes a custom_attributes block matching the API response structure.
  • A terraform refresh does not update the custom attributes in the state file.
  • The API response JSON for the queue includes the custom_attributes field populated correctly.

It seems the import process does not fetch the full resource definition from the API, or perhaps the provider requires a specific flag to include custom attributes during the import phase. Is there a documented method to force a full state sync for custom attributes during an import operation? Or should we be manipulating the state file manually using terraform state replace-provider or similar commands to align the local state with the remote API data?

We are hesitant to recreate the queue in production due to the potential disruption to active routing rules and agent assignments. Any insight into how the provider handles complex nested attributes during import would be appreciated.

2

You’re running into a known limitation with the current version of the Genesys Cloud Terraform provider. The import command only pulls the core schema fields-name, description, member IDs, and basic wrap-up codes. It explicitly skips the custom_attributes map because the provider treats those as volatile data that might change outside of IaC control.

If you try to force a terraform apply after importing, it’ll likely try to remove those attributes, which is not what you want.

The workaround is to manually extract the attributes and add them to your .tf file before running the plan. Here is how I usually handle it.

First, get the queue ID from the URL or your previous import output. Then hit the API directly to grab the JSON payload.

curl -X GET "https://api.mypurecloud.com/api/v2/routing/queues/{queueId}" \
 -H "Authorization: Bearer ${ACCESS_TOKEN}" | jq '.custom_attributes'

Take that JSON output and paste it directly into your Terraform configuration under the custom_attributes block for that specific queue resource.

resource "genesyscloud_routing_queue" "my_queue" {
 name = "Support Team"
 # ... other config ...

 custom_attributes = {
 "sla_target" = "60"
 "region" = "US_West"
 }
}

After that, run terraform plan. It should show no changes if the values match exactly. If the types don’t match (e.g., string vs integer), Terraform will complain. Make sure you quote all values in the HCL block since the API often returns strings for these key-value pairs.

It’s a bit manual, but it’s safer than letting the provider wipe out your custom data during a sync. I’ve seen teams lose custom attributes on accident when they assumed the import was fully recursive.