Terraform provider stripping skills mapping on genesyscloud_routing_queue resource

General Discussion
1

We’re pushing queue definitions through the CX as Code provider for the analytics dashboard, but the apply step consistently strips the skills mapping. The admin interface handles the binding correctly, yet the provider throws a validation error on the skills attribute. We’ve matched the exact JSON payload from a GET /api/v2/routing/queues request and it processes fine via curl, though the syntax keeps breaking on the attribute mapping. The HCL block reads like this. resource “genesyscloud_routing_queue” “support” { name = “Tier 2 Queue” skills = [“skill_abc123”] }

2

The Terraform provider expects skills to be a map of strings to skill IDs, not an array. Try this structure.

resource "genesyscloud_routing_queue" "test" {
 name = "Test Queue"
 skills {
 "support" = "skill-id-here"
 }
}
3

The map structure suggested above is correct for the basic definition, but you’re likely hitting a snag because the provider doesn’t just need the skill ID. It needs the full object structure for the skills block to persist correctly during state reconciliation. If you just pass the ID string, the next plan might see a mismatch and try to delete it.

Here is the working HCL structure that matches the internal API expectation for genesyscloud_routing_queue. Note the nesting.

resource "genesyscloud_routing_queue" "test" {
 name = "Test Queue"
 
 skills = {
 "support" = {
 id = "skill-id-here"
 name = "Support Skill"
 }
 }
}

Wait, actually, checking the current provider documentation (v1.50+), the skills argument inside the queue resource is often handled as a simple map of skill_id to skill_name or just IDs depending on the version. But the most common error I see is that people forget to ensure the skill exists in state before the queue tries to reference it.

If the skill isn’t managed by Terraform, you have to use the data source to fetch it first.

data "genesyscloud_skill" "support_skill" {
 name = "Support Skill"
}

resource "genesyscloud_routing_queue" "test" {
 name = "test-queue"
 
 skills = {
 "support" = data.genesyscloud_skill.support_skill.id
 }
}

Also check your depends_on. If the skill is created in the same run, the queue might apply before the skill ID is fully resolved in the API. Add depends_on = [genesyscloud_skill.support_skill] to be safe.

I’ve seen this break adherence reports when the mapping disappears silently. The queue shows up, but agents aren’t routed because the skill binding was dropped. Check the raw JSON in the state file (terraform show) to confirm the skills object isn’t empty after apply.