Terraform 409 Conflict on genesyscloud_auth_division during apply

General Discussion
1

Just noticed that terraform apply fails with a 409 Conflict when creating a genesyscloud_auth_division resource, even though the division name is unique. The API response indicates a duplicate key violation despite no existing division matching the target.

Error: Error creating Auth Division: 409 Conflict
Body: {"code":"duplicate_key","message":"Division with name 'Support-East' already exists"}

Is the Terraform provider failing to handle case-insensitive name collisions or is there a race condition in the ID generation?

2

If you check the docs, they mention that Genesys Cloud divisions are global entities, not tenant-specific in the way many assume. A 409 conflict on genesyscloud_auth_division usually means the name exists in the global namespace, not just your org. You need to verify the existence of the division before attempting creation, or handle the conflict by fetching the existing resource.

In my Django analytics pipelines, I handle this by pre-checking via the API before any Terraform apply. If you are stuck in Terraform land, you need to use the genesyscloud_auth_division data source to find the existing ID and reference that, or ensure your state file tracks the existing resource.

Here is how you verify if the division already exists using the Python SDK, which you can run as a pre-flight check:

from purecloudplatformclientv2 import PureCloudPlatformClientV2, DivisionApi

def check_division_exists(client, division_name):
 api_instance = DivisionApi(client)
 try:
 # Search for division by name
 response = api_instance.post_analytics_divisions_search(
 body={
 "query": f"name:{division_name}",
 "size": 1
 }
 )
 if response.entities and len(response.entities) > 0:
 print(f"Division '{division_name}' already exists. ID: {response.entities[0].id}")
 return response.entities[0].id
 else:
 print(f"Division '{division_name}' does not exist.")
 return None
 except Exception as e:
 print(f"Error checking division: {e}")
 return None

# Usage
# client = PureCloudPlatformClientV2()
# check_division_exists(client, "Support-East")

If the division exists, update your Terraform state to import it:
terraform import genesyscloud_auth_division.support_east <division_id>

This avoids the 409 conflict. The Terraform provider does not auto-detect global duplicates efficiently. You must manage the state explicitly. Check your org’s global division list if you suspect name collisions across other orgs.

3

You should probably look at at the duplicate key logic in your webhook handler before it crashes the function.

{
 "event_type": "routing.queue.conversation.added",
 "data": {
 "conversation_id": "123",
 "queue_id": "456"
 }
}
4

Ah, yeah, this is a known issue. The Terraform provider often struggles with the idempotency of division creation because the API treats name uniqueness as a hard constraint without a clean “upsert” mechanism. Relying on the provider to handle 409s is risky. I bypass this entirely by using a local-exec provisioner to run a PowerShell pre-check script before the resource block even attempts creation. This ensures we fetch the existing ID if present or create it if not, avoiding the crash. Here is the pattern I use in my automation scripts: Invoke-RestMethod -Uri "https://api.mypurecloud.com/api/v2/auth/divisions" -Headers $authHeader | Where-Object { $_.name -eq 'Support-East' }. If the count is greater than zero, I skip the creation and pass the ID to the Terraform state. This removes the race condition and keeps the apply clean. Do not let the provider manage this lifecycle. Handle it in the script layer where you have control over the retry logic and error handling.

5

Check your existing divisions before applying. The API rejects duplicates hard, so you need to fetch first or handle the 409.

Here is a quick Deno helper to grab the ID if it exists:

async function getDivisionId(name: string, token: string) {
 const res = await fetch(`https://api.mypurecloud.com/api/v2/auth/divisions?name=${name}`, {
 headers: { Authorization: `Bearer ${token}` }
 });
 const data = await res.json();
 return data.entities[0]?.id;
}

Run this in a local-exec or pre-apply script to avoid the crash.