migrating our contact center configuration to infrastructure-as-code using the Genesys Cloud Terraform provider. The specific challenge involves defining a queue that requires both routing skills and language skills. The documentation suggests using the genesys_cloud_routing_queue resource, but the syntax for embedding skills directly into the queue definition is not immediately clear.
I have tried the following configuration:
resource "genesys_cloud_routing_queue" "support_queue" {
name = "Support Queue"
description = "General support"
skills {
id = "skill-id-123"
name = "Support"
}
}
Applying this results in a validation error regarding the skills block structure. It appears the provider expects a reference to an existing skill resource rather than an inline definition. How do we properly link pre-defined skill resources to the queue? We need to ensure the queue inherits the correct skill set without duplicating skill definitions in the state file.
The syntax for skills in the genesys_cloud_routing_queue resource trips people up because it’s not a simple string array. You have to nest the skill IDs inside the routing_skill_required and routing_language_required blocks, but the tricky part is that the provider expects specific sub-blocks for id and level if you want to define proficiency. If you just drop the ID in there without the structure, it fails silently or throws a validation error.
Here is how I structure it in my HCL files. Note that I usually pull the skill IDs from a separate data source or module output to keep things DRY, but for a quick test, hardcoding the IDs works fine.
resource "genesys_cloud_routing_queue" "my_queue" {
name = "Support Queue"
description = "Queue with specific skills"
# Define routing skills
routing_skill_required {
id = "abc123-skill-id"
level = 5 # Optional, but good practice
}
routing_skill_required {
id = "def456-skill-id"
level = 3
}
# Define language skills if needed
routing_language_required {
id = "en-US"
}
# Other standard queue settings
queue_type = "routing"
wrap_up_timeout = 60
}
One thing to watch out for is that the level field is optional in the API, but if you define it once, you should probably define it for all skills in that block to avoid drift issues during plan/apply cycles. Also, make sure the skills you are referencing actually exist in your org before applying. Terraform won’t create them for you in this resource block.
I usually run a terraform plan first just to see if the IDs resolve correctly. If you get a “skill not found” error, double-check your OAuth token has the routing:queue:view scope. It’s a common gotcha when testing locally against a different environment than where the skills live.
Another tip: if you are managing a lot of queues, consider using count or for_each with a map of skill IDs. It saves a ton of copy-pasting.