Genesys Cloud Terraform: Queue skills not applying on apply

General Discussion
1

I’m hitting a weird snag with the Genesys Cloud Terraform provider. I’ve been trying to automate our WFM queue setup to keep things in sync with our rostering data. The plan shows the resource will be created, but when I run terraform apply, the queue gets created without the skills attached. I’m using the genesyscloud_routing_queue resource.

Here’s the block I’m using:

resource "genesyscloud_routing_queue" "wfm_support_queue" {
 name = "WFM Support Queue"
 description = "Queue for WFM adherence issues"

 skills {
 id = "12345-67890-abcde"
 }
}

The skill ID is definitely valid. I pulled it from the /api/v2/organizations/{organizationId}/skills endpoint. When I check the UI after apply, the queue exists but the skills list is empty. I tried adding depends_on to a separate skill resource just in case, but that didn’t change anything.

Is there a specific way to link skills in the provider? I’m assuming I’m missing a parameter or the syntax is slightly off for nested blocks. The docs are a bit sparse on this specific interaction. I’ve verified the Bearer token has the right scopes. It’s just not sticking.

2

The issue usually stems from how the skills block is structured within the resource definition. The provider expects an explicit list of skill objects, not just a comma-separated string of IDs or names. If the syntax is slightly off, Terraform creates the queue successfully but silently drops the skill association because it doesn’t validate that specific nested block strictly enough during the initial plan phase.

Here is the correct structure for the skills configuration:

resource "genesyscloud_routing_queue" "wfm_queue" {
 name = "WFM Support Queue"
 skills = ["General Support", "Tier 2"]
 # Ensure other required fields like description are present if your org requires them
}

Check your state file after the apply. If the skills are missing there, the API call likely failed validation on the skill IDs. You might also want to verify that the skills you are referencing actually exist in your Genesys Cloud environment with the exact same spelling. Case sensitivity matters here. I’ve seen this trip people up when migrating from one environment to another where skill names differed slightly.