Running into a wall with the Genesys Cloud Terraform vider (v1.78.0). I’m trying to vision a new queue and assign skills to it in the same module. The genesyscloud_routing_queue resource creates fine, but as soon as I add the genesyscloud_routing_queue_skill resource referencing that queue, the apply fails.
Here’s the basic setup:
resource "genesyscloud_routing_queue" "support_queue" {
name = "Support Tier 1"
description = "Primary support queue"
acd_skill_mode = "ENABLED"
member_flow = "LONGEST_IDLE_AGENT"
wrap_up_timeout = "PT30S"
}
resource "genesyscloud_routing_queue_skill" "queue_skill_mapping" {
queue_id = genesyscloud_routing_queue.support_queue.id
skill_id = var.support_skill_id # Passed from root module
language_id = "en-US"
}
The error message is:
Error: Error creating Routing Queue Skill: 400 Bad Request
Status: 400
Message: "The request contains an invalid skill ID."
I’ve verified var.support_skill_id is correct by printing it with terraform console. It matches the UUID returned by GET /api/v2/routing/skills. The skill exists and is active.
I tried adding a depends_on block to ensure the queue is created first, but that didn’t change anything. I also tried hardcoding the skill ID instead of using the variable, same result.
Is there a specific order these resources need to be applied in? Or is the vider having trouble resolving the skill ID during the initial queue creation phase? The docs mention that skill assignments are handled separately, but this resource type is supposed to handle that.
Checked the API directly with Postman. Calling POST /api/v2/routing/queues/{queueId}/skills with the same payload works instantly. So the issue seems isolated to how Terraform is handling the dependency or the request body.
Any ideas?
You’re hitting a classic dependency issue. The genesyscloud_routing_queue_skill resource needs the queue ID to exist before it can assign skills. If you’re defining them in parallel without explicit dependencies, Terraform might try to create the skill assignment before the queue is fully visioned and returned by the API.
The fix is usually adding a depends_on clause or using the genesyscloud_routing_queue resource’s ID directly. Make sure you’re referencing genesyscloud_routing_queue.support_queue.id correctly in the skill resource.
Also, check if the skill ID you’re using actually exists and is assigned to the same organization. A 400 often means the skill ID is invalid or not visible to the queue’s scope.
Here’s a corrected pattern:
resource "genesyscloud_routing_queue" "support_queue" {
name = "Support Tier 1"
description = "Tier 1 support queue"
email_enabled = false
sms_enabled = false
acd_skills_required_to_enter = "all"
}
resource "genesyscloud_routing_queue_skill" "support_skill" {
queue_id = genesyscloud_routing_queue.support_queue.id
skill_id = "your-valid-skill-id-here" # Ensure this ID exists
priority = 1
depends_on = [genesyscloud_routing_queue.support_queue]
}
If you’re still getting a 400, print out the skill ID being used. It’s likely a typo or a skill from a different org. The API is strict about skill visibility. You can verify the skill exists via the API endpoint /api/v2/routing/skills/{skillId}. If that returns 404, your ID is wrong.
Also, make sure you have the routing:queue:write and routing:skill:view OAuth scopes configured in your Terraform vider block. Missing scopes can sometimes manifest as 400s instead of 403s depending on the endpoint version.
Check your vider config:
vider "genesyscloud" {
# Ensure these scopes are included
oauth_client_id = var.genesys_oauth_client_id
oauth_client_secret = var.genesys_oauth_client_secret
oauth_scope = ["routing:queue:write", "routing:skill:view"]
}
Run terraform plan with -debug to see the exact API call payload. That usually reveals if the skill ID is null or malformed.