Terraform CX as Code provider rejecting skills block on routing queue

General Discussion
1

Trying to spin up a routing queue with specific skill assignments via Terraform, but the provider keeps barfing on the skills block. We’re running genesyscloud provider 1.42.0 against our asia-pacific-1 tenant. The HCL looks solid on paper, yet terraform apply throws a validation error about mismatched skill IDs.

Here’s the resource block I’m dropping into the module:

resource "genesyscloud_routing_queue" "support_eng" {
 name = "Engineering Support"
 description = "Tier 2 engineering queue"
 enabled = true

 skills {
 name = "cloud_platform"
 level = 5
 }
 skills {
 name = "api_integration"
 level = 3
 }
}

The error message points straight to the skills attribute. Says it expects a map of strings but gets a list of objects. I’ve checked the docs and the OpenAPI spec, both show skills as an array of objects with name and level. Maybe the Terraform wrapper is doing some weird flattening behind the scenes? Or is there a separate data source lookup I need to wire in first?

Running terraform plan just hangs on that block before spitting out Error: expected skills to be a map, got list. We’ve got a pipeline that auto-generates queues from a JSON manifest, so hardcoding skill IDs isn’t really an option. The JS SDK handles this fine when we POST to /api/v2/routing/queues, but the IaC path feels broken. Anyone else hit this mismatch when wiring up skills in the provider? What’s the actual HCL syntax the parser wants?

Tried swapping it to a map(string) format but the provider rejects the level field entirely. The REST API accepts the JSON payload without complaints, so the schema definition in the Go backend must be misaligned with the actual endpoint contract.

Checked the state file, nothing weird there. Just stuck on the schema validation.

2

The provider expects a list of strings, not a complex object. You’re likely passing the wrong type in that skills block.

Try this minimal config.

skills = ["skill-id-1", "skill-id-2"]
3

That list of strings works for the initial creation, but it’s brittle if you’re pulling skills from other modules or dynamic data sources. The genesyscloud provider has a dedicated data source that handles the lookup and dependency resolution much cleaner.

Instead of hardcoding IDs, you can fetch the skills by name or external ID first. This way, if a skill gets recreated or renamed in the UI, your Terraform state doesn’t drift unexpectedly.

data "genesyscloud_routing_skill" "support_skill" {
 name = "Technical Support"
}

data "genesyscloud_routing_skill" "general_skill" {
 name = "General Inquiry"
}

resource "genesyscloud_routing_queue" "main_queue" {
 name = "Main Support Queue"
 acdskillrequirement = "OPTIONAL"
 
 skills = [
 data.genesyscloud_routing_skill.support_skill.id,
 data.genesyscloud_routing_skill.general_skill.id
 ]
}

This pattern is way safer for CI/CD pipelines. You’re not guessing at UUIDs, you’re referencing actual platform entities. Just make sure the skills exist in the target environment before you run the apply, or you’ll hit a dependency error.