Could someone explain why genesyscloud_routing_queue data source fails with 404 when referencing an existing queue by name?
data "genesyscloud_routing_queue" "my_queue" {
name = "Support Tier 1"
}
The queue exists in Genesys Cloud. The provider logs show it calls /api/v2/routing/queues but returns empty. Is name lookup case-sensitive or scoped to a specific division in the API call?
My usual workaround is to checking the division ID. docs state “if no divisionId is specified, the provider defaults to the user’s primary division.”
The queue exists in Genesys Cloud. The provider logs show it calls /api/v2/routing/queues but returns empty. Is name lookup case-sensitive or scoped to a specific division in the API call?
the issue is the scope. your terraform auth token might be tied to a different division than where “Support Tier 1” lives. the API call /api/v2/routing/queues without a divisionId parameter only searches the default division. if the queue is in “Global” or another sub-division, the search returns null, causing the 404.
fix it by adding the division ID explicitly:
data "genesyscloud_routing_queue" "my_queue" {
name = "Support Tier 1"
division_id = "00000000-0000-0000-0000-000000000000" # Replace with actual ID
}
also check if the name has trailing spaces. the docs say “exact match on name attribute.” i copy-pasted from the UI once and it failed because of invisible whitespace. trim the string if needed.
It depends, but generally… relying on name-based lookups for data sources is a ticking time bomb in multi-environment setups. The suggestion about division scope is correct, but it misses the bigger risk: name collisions and drift. If you promote config from Dev to Prod, and a queue gets renamed or duplicated, your data source fails or points to the wrong resource. This breaks deployment gates silently until runtime.
I handle this by enforcing ID-based references via workspace variables instead of dynamic lookups. It’s more verbose but prevents accidental cross-environment contamination. Here is how I structure it in my release pipelines:
# variables.tf
variable "queue_id_support_tier1" {
type = string
description = "ID of Support Tier 1 queue. Do not use name lookups in prod."
}
# main.tf
resource "genesyscloud_routing_queue" "main" {
name = var.queue_name
description = var.queue_desc
# Use the ID directly if managing the resource,
# or pass var.queue_id_support_tier1 if referencing external state
}
If you absolutely must use a data source, add a division_id constraint and enable terraform plan checks in your CI pipeline to catch 404s before apply. But even then, I prefer pulling IDs from a shared state file or a secrets manager. The /api/v2/routing/queues endpoint returns a list, and without a strict divisionId filter, the provider might pick the first match alphabetically, which is rarely what you want in Prod.
Also, check your OAuth client’s assigned divisions. If the service account used by Terraform isn’t in the same division as the queue, the API returns an empty list regardless of the name. Verify the division_id in the provider block:
provider "genesyscloud" {
client_id = var.genesys_client_id
client_secret = var.genesys_client_secret
base_url = var.genesys_base_url
division_id = "7a1b2c3d-4e5f-6a7b-8c9d-0e1f2a3b4c5d" # Explicitly set this
}
Fix the division scope first, then move to ID-based references to avoid future headaches during config promotions.
This has the hallmarks of a classic division scope mismatch. The Genesys Cloud API strictly partitions resources by division ID. If your Terraform provider uses a token bound to the Global division, but “Support Tier 1” lives in a specific sub-division, the /api/v2/routing/queues call returns an empty list.
Verify the division ID explicitly in your HCL config.
Use the ID directly instead of relying on name lookups for production stability.
Here is the robust pattern:
data "genesyscloud_routing_queue" "my_queue" {
name = "Support Tier 1"
division_id = "e4b2c1d0-9988-7766-5544-332211009988" # Explicit division
}
I process high-throughput events in my gRPC microservice, and implicit scoping causes silent failures during batch updates. Always pin the division_id. It prevents race conditions when multiple environments share similar queue names. Check your OAuth token’s associated divisions in the Admin console to ensure alignment.