Genesyscloud_user schema break in CX as Code v1.35.0?

General Discussion
1

Just bumped our TF provider to v1.35.0 and the genesyscloud_user resource is throwing a fit. The routing_email field used to accept a plain string, but now terraform plan screams about an unexpected attribute. I’m passing routing_email = "user@gen.co" like always. Is the schema expecting a nested block now? The docs haven’t updated yet. Here’s the error: Error: Attribute routing_email expected type string, got object. Am I missing something or is this a breaking change they didn’t document?

2

Cause:
v1.35.0 aligned the TF schema with the underlying API structure. routing_email is no longer a flat string. It’s a nested block now. The docs lagged behind the release.

Solution:
Wrap the email in a routing_email block.

resource "genesyscloud_user" "test_user" {
 name = "Test User"
 email = "user@gen.co"
 
 routing_email {
 email_address = "user@gen.co"
 }
}

Check the provider changelog for other breaking changes. They usually batch schema updates.

3

The nested block works, but you’re going to hit a wall when you try to set the routing_skill or routing_language inside that same user resource. The provider still treats those as separate arrays at the root level, which creates a sync nightmare. If you change the email in the block, Terraform might flag a diff on the skills because it doesn’t fully understand the dependency chain yet.

I’d recommend bypassing the high-level genesyscloud_user resource for anything complex. Use the raw API endpoint via a null_resource and local-exec or the http provider if you’re on TF 1.3+. It’s messy, but it gives you exact control over the JSON payload without fighting the provider’s opinionated schema changes.

Here’s a quick curl snippet to test the payload structure before you commit it to TF:

curl -X PUT "https://api.mypurecloud.com/api/v2/users/{userId}" \
 -H "Content-Type: application/json" \
 -H "Authorization: Bearer ${GENESYS_ACCESS_TOKEN}" \
 -d '{
 "routing": {
 "email": {
 "emailAddress": "user@gen.co"
 },
 "skills": [
 {
 "skill": {
 "id": "skill-id-123"
 },
 "proficiency": 5
 }
 ]
 }
 }'

If you stick with the TF resource, just be ready to write a custom diff suppressor if the provider starts reordering the skill array on every plan. It’s a known quirk. The API accepts the object, but the state file comparison is brittle. Check the genesyscloud_routing_email resource too. It might be the intended path, though the docs are sparse.