Why is this setting causing a 404 when I try to reference an existing queue by name in my Terraform configuration? Error: 404 Not Found
Error: resource "genesyscloud_routing_queue" not found
│
│ with data.genesyscloud_routing_queue.existing,
│ on main.tf line 12, in data "genesyscloud_routing_queue" "existing":
│ 12: data "genesyscloud_routing_queue" "existing" {
│ 13: name = "Support_Tier1"
I am trying to build a test suite that dynamically references existing resources to avoid hardcoding IDs in Postman environment variables. I have verified the queue exists via the API:
However, the Terraform data source genesyscloud_routing_queue consistently returns a 404 during terraform plan. The resource name matches exactly, including case sensitivity. I am using the latest provider version. Is there a specific attribute I need to set or a delay required before the data source can resolve the name? I need this to work reliably in my CI/CD pipeline before triggering Newman runs.
This happens because the inherent instability of name-based lookups in Terraform when dealing with Genesys Cloud resources, as names are not globally unique identifiers and can contain special characters that require strict escaping. The provider attempts to resolve the name via the /api/v2/routing/queues endpoint, which often returns multiple matches or fails if the name casing does not exactly match the backend storage. You should switch to using the id attribute if you know the queue ID, or use the genesyscloud_routing_queue data source with a search_query parameter that leverages OData filtering for more precise matching. Specifically, use search_query = "name eq 'Support_Tier1'" instead of the name attribute alone, ensuring the quotes are properly escaped in your HCL. This forces the provider to use the correct OData filter syntax against the reporting API layer, reducing ambiguity. If the queue was recently created, also ensure your Terraform state is refreshed, as there can be a propagation delay between the UI and the underlying data store that causes transient 404s during initial plan runs.
Check your Terraform provider authentication context and the specific Genesys Cloud organization ID associated with the OAuth client credentials. The 404 error often stems from a mismatch between the org ID used for the API token generation and the org ID where the queue “Support_Tier1” actually resides. When using the Genesys Cloud Terraform provider, it relies on the genesyscloud_auth data source to establish the connection. If your CI/CD pipeline or local environment is switching orgs, the provider might be querying a different org context than expected.
Here is how I structure my Terraform modules to ensure strict org context alignment, which mirrors how I handle scope validation in my PySpark Glue jobs:
data "genesyscloud_auth" "my_auth" {
client_id = var.genesis_client_id
client_secret = var.genesis_client_secret
org_id = var.genesis_org_id # Explicitly define the org ID
}
provider "genesyscloud" {
auth = data.genesyscloud_auth.my_auth
}
data "genesyscloud_routing_queue" "existing" {
name = "Support_Tier1"
}
If you are still encountering issues after verifying the org ID, consider using the genesyscloud_routing_queue data source with a depends_on block if the queue is created within the same Terraform run. This ensures the state file has registered the resource before the lookup occurs. Additionally, verify that the OAuth client has the necessary scopes, specifically routing:queue, to read queue metadata. In my ETL workflows, I often see similar permission-based 404s when the service account lacks read access to specific routing entities. Ensure your client credentials are not restricted to a limited scope that excludes routing queue lookups.