Genesyscloud_user email field becoming required in Terraform v1.35.0?

Running into a schema shift with the latest provider update. We’ve been using the genesyscloud_user resource for years without explicitly setting an email, relying on the system defaults or manual entry. Just bumped to v1.35.0 and our existing state files are throwing a fit during plan.

Here’s the error popping up:

Error: Attribute "email" is required

 on main.tf line 12, in resource "genesyscloud_user" "agent":
 12: name = var.agent_name

An argument named "email" is not expected here.

Wait, that message is confusing. It says it’s required, then says it’s not expected? No, actually, looking closer at the diff, it seems like the provider is now demanding the attribute be present in the config, but if I add email = "test@genesys.com", it complains about validation or conflicts with the auto-generated one.

I’ve tried:

  • Reverting to v1.34.2 → works fine, no changes detected.
  • Adding email = "placeholder@genesys.com" → plan passes, but apply fails with a 400 Bad Request saying the email is invalid or duplicate.
  • Checking the docs for v1.35.0 → the schema section for genesyscloud_user lists email as Optional. But the runtime behavior disagrees.
  • Running terraform state show on an existing user → it shows the email is populated in state.

Is this a known breaking change where optional fields became required in the config block? Or is my state file out of sync? The error message is super vague about why it’s rejecting the plan.

Here’s a snippet of the resource:

resource "genesyscloud_user" "agent" {
 name = var.agent_name
 email = var.agent_email # Tried commenting this out and in
 division_id = var.division_id

 user_roles {
 role_id = var.agent_role_id
 }
}

If I comment out the email line, it crashes. If I leave it, it might crash on apply depending on the value. Feels like a bug in the provider logic for this version.

Terraform is just enforcing what the API already requires. You gotta set the email attribute in your HCL or the plan will fail every time. It’s not a bug, it’s just strict validation catching up.