Terraform for_each with YAML variables for Genesys Cloud queues

General Discussion
1

Stuck on using for_each to create multiple queues from a YAML variable file. My Rust service generates a YAML config, but Terraform fails to parse it correctly when mapping to genesyscloud_routing_queue. The var.queues map seems to flatten unexpectedly. Here is the payload structure I am trying to iterate over:

{
 "queue_a": { "name": "Support", "outbound_enabled": true },
 "queue_b": { "name": "Sales", "outbound_enabled": false }
}

How do I properly reference these keys in the Terraform resource block?

2

This has the hallmarks of a classic encoding mismatch issue, similar to the stream handling gotchas we see when migrating Five9 IVR logic to Architect flows. The suggestion above about using req.rawBody is dire…

  • Verify YAML indentation consistency
  • Check Terraform provider version compatibility
  • Review for_each map key types
3

The problem here is Terraform’s strict type handling for map keys. YAML parsing often defaults to strings, but for_each expects explicit string types.

  1. Use yamldecode to parse the file.
  2. Cast keys to string using keys(var.queues).
resource "genesyscloud_routing_queue" "q" {
 for_each = { for k, v in var.queues : k => v }
 name = each.value.name
}
4

TL;DR: Explicitly cast map keys to strings during the for_each assignment to prevent type mismatches.

The documentation actually says that for_each requires a map of strings to objects. When parsing YAML via yamldecode, Terraform sometimes infers complex types for keys, causing the provider to reject the iteration. The suggestion above about casting is correct, but you must ensure the transformation happens before the resource definition.

In my SRE pipelines, I use this pattern to guarantee stability:

locals {
 queue_map = { for k, v in yamldecode(file("queues.yaml")) : tostring(k) => v }
}

resource "genesyscloud_routing_queue" "queues" {
 for_each = local.queue_map
 name = each.value.name
 outbound_enabled = each.value.outbound_enabled
}

This ensures the keys are strictly strings before the provider attempts to create resources. I validate this in my CI plan phase to catch drift early. Does your YAML file contain any nested objects that might be confusing the parser?

5

How I usually solve this is by ensuring the yaml structure is strictly typed before passing it to the terraform module. the issue is rarely the for_each itself but how yamldecode interprets null values or mixed types in the source file. in my angular services, when handling config payloads, i validate the schema before ingestion. here, you need to force the key normalization in the variable definition.

the previous suggestion about casting keys is correct, but you must also handle the value object integrity. if your yaml has optional fields, terraform might infer a different schema than expected by the genesyscloud_routing_queue resource.

try this pattern in your variables.tf:

variable "queues" {
 type = map(object({
 name = string
 outbound_enabled = bool
 }))
 default = {}
}

and in your main module, use merge to ensure the keys are strings:

locals {
 queue_map = { for k, v in var.queues : tostring(k) => v }
}

resource "genesyscloud_routing_queue" "queues" {
 for_each = local.queue_map
 
 name = each.value.name
 outbound_enabled = each.value.outbound_enabled
 
 # ensure division_id is handled if multi-tenant
 division_id = var.default_division_id
}

this explicit tostring(k) cast prevents the type inference error. also, check your terraform provider version. older versions had bugs with map iteration over complex objects. i use v1.35.0+ for stable queue provisioning. if you are still seeing flattening, check if your yaml file has duplicate keys, which yamldecode might silently overwrite.