Hey folks,
Running into a snag with the Genesys Cloud Terraform provider while trying to migrate some legacy queue configurations. We have a bunch of existing routing queues that we don’t want to recreate, so I’m using data sources to reference them by name. The issue is that the lookup fails if the name isn’t an exact match, or if there are duplicates, which seems to be the case here.
Here’s the snippet:
data "genesyscloud_routing_queue" "existing_queue" {
name = "Support - Tier 1"
}
resource "genesyscloud_routing_email_integration" "email_int" {
name = "Tier 1 Email"
routing_queue_id = data.genesyscloud_routing_queue.existing_queue.id
}
When I run terraform plan, it throws an error saying it can’t find the resource. I checked the API directly using a quick curl to /api/v2/routing/queues and the name is definitely there. It looks like the provider’s data source implementation might be doing a strict equality check rather than a contains or regex match.
Is there a way to make the data source more flexible? Or do I have to switch to looking up by ID directly? Hardcoding IDs defeats the purpose of IaC.
Also, I noticed the provider docs mention a name_match attribute in some resources but not in the data source definition. Am I missing something?
Look, relying on names for data sources is always a bit of a gamble in Genesys Cloud, especially if your naming conventions aren’t strictly enforced across the org. The provider tries to find the first match, and if you have “Support” and “Support - Priority”, it might pick the wrong one or throw an error if it sees multiple candidates. It’s much safer to query by the specific ID if you can pull it from the UI or an existing export. That way, you bypass the name collision entirely. You can also use the search attribute with a more unique substring, but that still carries risk.
Here is how I usually handle this to keep the state file clean and predictable. I grab the ID once, hardcode it in a variable file, and then reference that variable in the data source. It’s a tiny bit more manual upfront, but it saves hours of debugging later when someone renames a queue and breaks the pipeline.
variable "queue_id" {
description = "ID of the existing support queue"
type = string
default = "a1b2c3d4-e5f6-7890-abcd-ef1234567890" # Replace with actual ID
}
data "genesyscloud_routing_queue" "support" {
id = var.queue_id
}
resource "genesyscloud_routing_queue" "main" {
name = "Customer Support"
description = "Main support queue"
# Reference other resources using the data source
}
This approach is verbose, I know, but it removes ambiguity. The Terraform provider for Genesys Cloud is still maturing, so explicit IDs are your best friend right now. Don’t fight the API’s search behavior. Just pin it down.