Trying to import an existing queue - queue-a - into Terraform, but it’s consistently failing to attach to the skill - skill-x. The import command runs clean, no errors there, but the skill association just…doesn’t stick. Feels like a state drift issue, but I’ve blown away the state file, re-authenticated, and re-run the import. Still no dice.
Here’s the HCL:
resource "genesys_cloud_queue" "imported_queue" {
name = "queue-a"
division_id = "1234-abcd-5678-efgh"
lifecycle {
ignore_changes = [
skill_ids
]
}
}
resource "genesys_cloud_skill" "imported_skill" {
name = "skill-x"
division_id = "1234-abcd-5678-efgh"
}
resource "genesys_cloud_queue_skill" "queue_skill" {
queue_id = genesys_cloud_queue.imported_queue.id
skill_id = genesys_cloud_skill.imported_skill.id
}
The API is returning a 200, which is annoying. We’re on terraform v1.6.6 and the provider version is v4.18.0. Latency to the Genesys Cloud API from Chicago is brutal today - taking like 300ms just to hit the endpoint. Think the Terraform provider might be timing out before the association propagates or something. Quick win to get this shipped, honestly.
The skill association is separate from the queue resource itself. Terraform usually struggles with these linked resources during import. It’s a common problem - we’ve seen this before in the community, actually, with queue-skill assignments. The skill needs a dedicated resource block in Terraform, referencing the queue.
Try adding this to your HCL. It might help with the import.
resource "genesys_cloud_queue_skill_assignment" "imported_skill_assignment" {
queue_id = genesys_cloud_queue.imported_queue.id
skill_id = "skill-x"
}
It’s similar to BYOC edge promotions - the linked items need to be explicitly defined. Sometimes Terraform’s import process doesn’t pick up these dependencies automatically. There was a post last month about a similar issue with data actions, so you’re not alone.
2 Likes
The suggestion above - that the skill association isn’t directly managed within the queue resource - is absolutely correct, and it’s a pattern that appears repeatedly when importing complex relationships into Terraform (it’s not unique to Genesys Cloud, but it feels more acute here). Terraform treats these linked resources - queue-skill assignments, agent-skill assignments, even routing profiles tied to queues - as independent entities, and the import process doesn’t automatically resolve those linkages. It’s a consequence of how the API exposes those relationships, honestly.
What often happens is the queue itself imports fine, but the association with the skill is left dangling - a sort of orphaned record - because Terraform isn’t told to explicitly create that link during the import. The genesys_cloud_queue_skill_assignment resource, as mentioned, is the key. You’ll need to define that resource, referencing both the queue ID and the skill ID, and then import it separately. It’s a two-step import process, essentially. You might even run into an issue where the order of operations matters (import the queue first, then the skill assignment), though I’ve not consistently encountered that. Just be prepared to refresh your Terraform state if something goes wrong.
1 Like
Cause: Terraform import is garbage for linked resources - especially QUEUE_SKILL_ASSIGNMENTS. The state file gets confused.
Solution: Forget the import. Manually remove the skill assignment via the API (by updating the queue’s skill expressions) - then re-apply via Terraform. It’s faster than chasing ghosts in the state. YMMV.
curl -X DELETE https://api.mypurecloud.com/v2/skills/{skillId}/queueAssignments/{queueId} -H "Authorization: Bearer {token}"
That’s what I said earlier - delete the assignment via the API before Terraform tries to manage it. It’s a mess with imports. The state file just…gets stuck.
Someone in the thread mentioned the import cess doesn’t auto-resolve these things - correct. We’ve seen this repeatedly with queues and skills. It’s not limited to Terraform - BYOC trunks are similar.
Just a hunch, but I suspect Terraform tries to create a new assignment before deleting the existing one, and the API rejects it. Hence the import failing silently. Delete first, then let Terraform do its thing. It’s faster than digging through state. I’ve done it a dozen times this month.