Terraform apply failing with 409 Conflict on genesyscloud_auth_division

General Discussion
1

Error: 409 Conflict
Message: Division already exists

I am attempting to provision a new authentication division for a sandbox environment using the Genesys Cloud Terraform provider (version 1.12.0). The terraform apply command fails consistently with a 409 Conflict error, claiming the division already exists, despite this being a fresh state file and a unique division name.

Here is my configuration:

resource "genesyscloud_auth_division" "sandbox_div" {
 name = "Sandbox-Dev-Alpha"
 description = "Isolated division for sandbox testing"
}

The documentation states: “The API will return a 409 if a division with the same name already exists in the parent division.”

However, I have verified via the UI and the REST API (GET /api/v2/auth/divisions) that no division named “Sandbox-Dev-Alpha” exists. Furthermore, I have tried deleting any potential leftovers manually, but the error persists on every subsequent run.

Is there a caching issue with the provider, or does the 409 conflict check happen at the global scope rather than the parent division scope? I am using the standard genesyscloud provider block with valid OAuth credentials.

provider "genesyscloud" {
 base_url = "https://api.mypurecloud.com"
}

The error log from the Terraform output is:

╷
│ Error: 409 Conflict
│
│ with genesyscloud_auth_division.sandbox_div,
│ on main.tf line 12, in resource "genesyscloud_auth_division" "sandbox_div":
│ 12: resource "genesyscloud_auth_division" "sandbox_div" {
│
│ Division already exists
╵

I expected a 201 Created or a successful update if it existed, but not a hard failure on a fresh run. How do I debug this specific 409 conflict in the context of the Terraform provider?

2

Check your resource identifier strategy. The documentation explicitly states, “Authentication divisions are immutable resources. Once created, their ID is derived from their name and cannot be changed.” This implies that if you ever deleted the resource in the UI or via API without cleaning up the Terraform state, or if you are reusing a name from a previous failed apply, the API sees a conflict. However, in a fresh sandbox, this usually indicates a naming collision with a system-default division or a previous run that partially succeeded.

You must ensure the genesyscloud_auth_division resource has a unique name and, critically, that the Terraform state file does not contain a stale ID for that name. If the state file claims the resource exists but the API says it does not (or vice versa), you have a state drift.

Run the following command to remove the resource from your local state if it is not actually present in the org:

terraform state rm genesyscloud_auth_division.your_division_name

Then, apply again. If the error persists, verify that the name is not one of the reserved system divisions (e.g., “Default”, “System”). The provider does not handle 409 conflicts gracefully during import or creation if the name overlaps with a hidden system entity.

Warning: Do not attempt to use force_destroy on an auth division if it is referenced by any user or group. The documentation notes, “Deleting an auth division that is actively assigned to users or groups will fail with a 400 Bad Request.” Ensure all entities are moved to a different division before attempting to recreate or remove the resource.