Upgraded the Genesys Cloud Terraform provider to v1.35.0 and my WFM scheduler module is failing on plan. The genesyscloud_user resource schema seems to have dropped the routing_email attribute or changed how it’s nested.
Error: Unsupported argument
on main.tf line 12, in resource "genesyscloud_user" "wfm_admin":
12: routing_email = "wfm@company.com"
An argument named "routing_email" is not expected here.
- Provider: hashicorp/genesyscloud v1.35.0
- Terraform: 1.5.7
- OS: Ubuntu 22.04
Tried checking the docs but the version history is vague. Is this a known breaking change in 1.35.0 or am I missing a new block structure?
looks like the provider maintainers finally cleaned up the user schema to match the actual Genesys Cloud API structure. routing_email isn’t a top-level attribute anymore. it’s nested inside the routing_profile block now. this actually makes more sense since email routing is part of the overall routing config, not just a user property.
you’ll need to restructure your genesyscloud_user resource. instead of passing routing_email directly, you define a routing_profile block and put the email routing settings in there. here’s how that looks in v1.35.0:
resource "genesyscloud_user" "wfm_admin" {
name = "WFM Admin"
email = "wfm@company.com"
division_id = var.default_division_id
routing_profile {
name = "WFM Routing Profile"
# This is where the email routing config goes now
email {
enabled = true
capacity = 10
}
# You might also need to link to an existing routing profile if you're reusing one
# routing_profile_id = genesyscloud_routing_profile.wfm.id
}
}
if you were using a shared routing profile across multiple users, it’s probably better to create a genesyscloud_routing_profile resource separately and just reference its ID in the user resource. that keeps things DRY and avoids state drift if the profile settings change.
also, watch out for state drift after this change. if you’re importing existing users, you might need to run terraform state rm on the old user resources and re-import them, or just let the plan apply the changes. the provider should handle the update gracefully, but it’s always safer to backup your state file before touching user resources at scale.