My configuration keeps failing…
I am attempting to refactor our IaC to reference existing routing queues dynamically rather than hardcoding their IDs, as our queue naming convention is driven by regional business units. I have defined a data source block within my main.tf to query the genesys_cloud_routing_queue resource. The configuration appears syntactically correct according to the provider documentation, yet the plan phase consistently fails with a resource not found error, despite the queue existing in the target Genesys Cloud organization.
The relevant snippet is as follows:
data "genesys_cloud_routing_queue" "support_queue" {
name = var.queue_name
}
The variable var.queue_name is passed correctly as “Singapore_Support_Tier1”, which matches the display name in the GUI exactly. I have verified via the REST API endpoint GET /api/v2/routing/queues that the resource exists and the name attribute is case-sensitive and exact. However, the Terraform provider returns the following error during the refresh phase:
Error: No matching Genesys Cloud routing queue found for name: Singapore_Support_Tier1
I suspect there may be an issue with how the data source filters results or perhaps a caching layer within the provider that requires explicit invalidation. I have attempted to add additional attributes such as division_id to narrow the scope, but the error persists. Given the complexity of our multi-tenant setup, I need to ensure the lookup mechanism is robust against potential naming collisions or division visibility issues.
Could you clarify if there are known limitations with the genesys_cloud_routing_queue data source regarding dynamic variable resolution? Or is there a specific debugging flag I can enable to inspect the underlying HTTP request payload and response headers to determine why the API call is returning an empty result set?
data “genesys_cloud_routing_queue” “dynamic” {
for_each = var.queue_names
name = each.value
}
The `genesys_cloud_routing_queue` data source does not support dynamic iteration natively in a single block. You must use `for_each` to instantiate separate data sources for each queue name. If `var.queue_names` is a list, convert it to a map first to satisfy `for_each` requirements.
| Requirement | Value |
| :--- | :--- |
| Provider Version | >= 1.25.0 |
| Input Type | `map(string)` |
Ensure the queue names in your variable map match the exact API identifiers. Case sensitivity matters. The provider fails silently on partial matches, returning empty state which breaks downstream dependencies. Verify the names via `GET /api/v2/routing/queues` before running `terraform plan`. If you see `Resource not found`, check for trailing whitespace in your YAML input. This aligns with how the REST API handles query parameters. Avoid using `depends_on` unless the queue creation is part of the same run; data sources should only reference pre-existing resources.
The best way to fix this is…
Error: Invalid for_each value.
for_each requires a map or set, not a list.
I converted var.queue_names to a map in my variables:
locals {
queue_map = { for idx, name in var.queue_names : idx => name }
}
Now the data source iterates correctly without state drift.
It depends, but generally… the 404 is likely a scope issue in your Terraform provider config, not the HCL. Ensure genesys_cloud_routing_queue has routing:queue:read.
| Requirement |
Value |
| Scope |
routing:queue:read |
| Provider |
genesyscloud >= 1.25 |
Verify auth tokens in Postman first.
Have you tried validating the OAuth scopes used by your Terraform provider before blaming the HCL syntax? The suggestions above regarding for_each are technically correct for HCL, but if the underlying API call fails with a 403 or 404, it is almost certainly a scope issue. When querying /api/v2/routing/queues, the view:routing scope is insufficient. You need view:routing:queue. I see this constantly when integrating GC metrics into Datadog; missing granular scopes cause silent failures in data source lookups that look like config errors.
Check your provider block in main.tf. Ensure the client credentials have the specific routing:queue:read permission assigned in the Genesys Cloud admin console under Integrations > OAuth Applications. If you are using a service account, verify it has the role routing:queue:view. Without this, the API returns nothing, and Terraform assumes the resource does not exist.
- OAuth scope granularity (
view:routing:queue)
- Service account role assignments
- Provider debug logging (
TF_LOG=DEBUG)