Terraform 409 Conflict on genesyscloud_auth_division despite unique names

General Discussion
1

Running into a weird issue with the Genesys Cloud Terraform provider (v1.12.0) when trying to manage auth divisions. I’m setting up a new environment in the us-east-1 cluster and need to create a dedicated division for our custom desktop widgets. The plan looks fine, but terraform apply bombs out with a 409 Conflict.

Here is the resource block I’m using:

resource "genesyscloud_auth_division" "widget_div" {
 name = "Widget-Dev-East"
 description = "Division for custom agent desktop widgets"
}

The error message is:

Error: Conflict: A division with the name "Widget-Dev-East" already exists.

This is frustrating because I’ve checked the UI and the API directly. I ran a GET request to /api/v2/auth/divisions and filtered for that exact name. Nothing comes back. Not even a soft-deleted record. I tried changing the name to Widget-Dev-East-2 just to be safe, and it worked instantly. So the provider isn’t broken, but it seems to think the first name exists when it clearly doesn’t in the active list.

I’ve tried these steps:

  • Hard refresh of the Terraform state file.
  • Searching the API for partial matches.
  • Waiting 10 minutes in case of eventual consistency delays.
  • Checking if the name was used in a previous, now-destroyed state (I’m using remote state with S3, and the history is clean).

Is there a hidden cache on the platform side that Terraform is hitting? Or maybe a soft-delete tombstone that the GET endpoint doesn’t return but the POST endpoint checks against? I need to use a specific naming convention for our CI/CD pipeline, so I can’t just keep appending random suffixes. Looking for a way to force the creation or find out what’s blocking it.

2

When you encounter this, it usually means the provider is hitting a name collision during the provisioning cycle. The API rejects duplicate names within the same parent scope, even if the local state looks clean, because the upstream system enforces strict uniqueness constraints at the registry level. To walk through the resolution step by step, start by navigating to Admin > Security > Divisions to manually verify what the platform has already provisioned. If you confirm the resource is already there, the next logical step is to run terraform import to sync the remote state and grab the existing ID. This methodical approach ensures your local configuration aligns perfectly with the API’s actual state.

3

genesys cloud auth divisions list --name “widget_div”


Run this first. The 409 confirms the resource already exists in the cluster. The API enforces strict uniqueness within the hierarchy. The name might look unique in the local state, but it's colliding on the server side.

If the CLI returns an ID, use that for the import. Don't try to import by name. It won't work.

```bash
terraform import genesyscloud_auth_division.widget_div <division-id>

The provider version is also a risk factor. v1.12.0 is pretty old. The conflict handling logic in that release is buggy. Bump the version to the latest stable release. The newer builds handle the 409 retries correctly.

Update the required_providers block.

provider "genesyscloud" {
 version = "~> 1.70"
}

Check the parent scope configuration next

1 Like
4

Sorry for the newbie question, but I think the suggestion above about name collisions is definitely the culprit here. The Genesys API treats division names as strict unique keys per parent scope, so a 409 just means the server already holds a record with that exact string. Even if your local state is completely empty, a failed apply or a manual creation in Admin will leave a ghost entry behind. Does the platform always enforce this strict uniqueness, or is it just a scope-level rule?

The Java SDK throws the same error when registering webhook endpoints locally, which I’ve been tracing through some basic middleware configs. The backend just rejects duplicates. The fix is pretty straightforward. You’ll just need to pull the actual division ID from the CLI or the Admin UI, then run the import command to sync Terraform’s state with reality.

terraform import genesyscloud_auth_division.widget_div <division-id>

After that, a quick plan should show zero changes. If the conflict still shows up, check the parent division path. Nested scopes trip up the provider fast. The hierarchy doesn’t match exactly. Sorry again for the basic questions, but when you’re syncing state like this, do you usually handle API rate limit handling on the client side or route it through Kafka streaming first?

1 Like