Just noticed that using the genesyscloud_routing_queue data source with a name lookup fails consistently, even when the resource exists in the target organization. I am attempting to build a declarative pipeline configuration that references existing routing queues to avoid hardcoding IDs in my Terraform modules. The goal is to fetch the queue ID dynamically based on the display name provided in the variable map.
I have verified that the queue Support-Team-Alpha exists in the Genesys Cloud admin interface and is accessible via the standard REST API at /api/v2/routing/queues. However, when I apply the following Terraform configuration:
data "genesyscloud_routing_queue" "support_alpha" {
name = "Support-Team-Alpha"
}
resource "genesyscloud_routing_skill_group" "sg" {
name = "SG-Alpha"
# ... other config
queue_ids = [data.genesyscloud_routing_queue.support_alpha.id]
}
The apply fails with:
Error: Error reading Routing Queue: GET https://myorg.mygenesyscloud.com/api/v2/routing/queues?name=Support-Team-Alpha returned 404 Not Found
I expected the provider to handle the name-to-ID resolution internally by querying the list endpoint and filtering by name. The documentation states:
“If name is specified, the provider will search for the first resource matching the name. If multiple resources match, the first one found is returned.”
This suggests the lookup should succeed if at least one match exists. I have checked for trailing spaces or case sensitivity issues, and the name matches exactly. Is there a known limitation with name-based lookups for routing queues in the current Terraform provider version, or is this a bug in how the provider constructs the query parameters? I need a reliable way to reference these IDs without manual maintenance.
It depends, but typically the genesyscloud_routing_queue data source requires an exact match for the name attribute, which often fails if there are trailing spaces or case sensitivity mismatches in the Genesys Cloud UI. The Terraform provider does not support partial name matching, so you must ensure the variable passed matches the queue name precisely. 1. Verify the exact queue name in the Genesys Cloud admin console, including any hidden whitespace. 2. Use the genesyscloud_routing_queue data source with the confirmed name. If the 404 persists, check if the queue is in a different division than your default scope. You can explicitly set the division_id in the data source configuration to narrow the search scope. Here is a working example:
data "genesyscloud_routing_queue" "support" {
name = "Support Team"
division_id = var.default_division_id
}
output "queue_id" {
value = data.genesyscloud_routing_queue.support.id
}
This approach avoids hardcoding IDs while ensuring the lookup targets the correct organizational unit. Remember that queue names must be unique within the specified division to prevent ambiguous lookups.
It’s worth reviewing at the genesyscloud_routing_queue data source docs again because it requires an exact match including trailing spaces. use the genesyscloud_routing_queue resource’s name attribute directly in your module inputs instead of relying on case-insensitive lookups that don’t exist in the provider.
data "genesyscloud_routing_queue" "support" {
name = var.queue_name # must match exactly, no trim
}
You need to understand that the Terraform provider’s data source lookup is strictly case-sensitive and does not tolerate leading or trailing whitespace, which is a common gotcha when queue names are managed via the UI or imported from CSVs. I ran into this exact friction while building a CLI tool for bulk queue auditing. The provider doesn’t perform fuzzy matching, so if your variable map has “Support-Team” but the API returns "Support-Team ", the lookup fails with a 404 or empty result. Always sanitize your input strings in your Terraform variables before passing them to the data source.
To debug this reliably outside of Terraform, I use a quick Python script with the PureCloud SDK to verify the exact string representation. This helps isolate whether the issue is in your Terraform variable definition or the Genesys Cloud object itself. Here is a snippet using the genesyscloud Python SDK to fetch and print the raw queue name:
from genesyscloud import RoutingApi
from genesyscloud.configuration import Configuration
config = Configuration()
config.host = "https://api.mypurecloud.com"
# Setup OAuth token here
routing_api = RoutingApi(config)
queues, _ = routing_api.get_routing_queues(page_size=20)
for q in queues.records:
print(f"Name: '{q.name}' | ID: {q.id}")
Once you confirm the exact string from the API response, update your terraform.tfvars to match it precisely. If you are dealing with legacy queues where names might have been modified manually, consider fetching the queue ID via a custom data source or a pre-flight script that outputs a JSON map of name to id. This approach bypasses the provider’s strict matching logic and gives you more control over resolution. I usually wrap this in a Click CLI command to generate the map file automatically before running terraform plan.
The simplest way to resolve this is to trace the actual API response. The provider strips whitespace, but the backend doesn’t. Use a span to inspect the raw /api/v2/routing/queues payload. Whitespace mismatches cause silent 404s.
data "genesyscloud_routing_queue" "support" {
name = trimspace(var.queue_name)
}