Genesyscloud_user schema change in v1.35.0 breaking existing state

General Discussion
1

Upgraded the CX as Code provider to v1.35.0 this morning and my TF plan is now screaming about the genesyscloud_user resource. The division_id argument seems to have shifted or become required in a way that wasn’t before.

Here’s the error:

Error: Error creating user: 400 Bad Request
Details: division_id is required

I’ve got dozens of users defined without explicit division_id in my legacy code, relying on the default. Now TF wants to force an update or recreate them. Is this a known breaking change in the docs? I don’t want to wipe out all my user states just to fix a schema mismatch. Anyone else hit this wall?

2

Look at the provider release notes again. The division_id isn’t just a soft requirement now. It’s strict. If you leave it blank in the HCL, the provider tries to send null or an empty string to the NICE CXone API, and the backend rejects it immediately with that 400.

You don’t need to hardcode the division ID in every single user block if you don’t want to. There’s a cleaner way to handle this in Terraform without refactoring your whole repo. Use a data source to pull the default division ID once, then reference it.

Here is the pattern I use:

data "genesyscloud_routing_division" "default" {
 name = "Default"
}

resource "genesyscloud_user" "agent" {
 name = "Test Agent"
 email = "agent@company.com"
 division_id = data.genesyscloud_routing_division.default.id
 
 # ... other attributes
}

This way, if your default division name changes or you move orgs, you only update the data source lookup. It keeps the user definitions clean.

Also, check your existing state file. If you ran terraform apply before the upgrade, your state might have stale attributes. You might need to run terraform import for existing users if the state drifted, but usually, just adding the division_id reference fixes the plan.

The error message is misleading because it says “required” but implies it was optional before. It’s not optional. The API contract changed. The provider just caught up to reality.

Make sure you’re using the latest provider version too. v1.35.0 had a hotfix for this exact issue in the patch releases. If you’re on 1.35.0 exactly, upgrade to 1.35.2 or higher. The earlier patches had a bug where the default division lookup failed silently.

Don’t forget to run terraform refresh after updating the HCL. It’ll update the state to match the new schema expectations.

3

The point above is correct. The API doesn’t accept nulls for division anymore, so you have to explicitly set it. Just grab the default division ID once and pass it to your user resources.