Trying to clean up some offboarded agents using the Python SDK. The goal is to remove the user record without nuking their historical interaction data in the reports. The docs say a DELETE on /api/v2/users/{userId} should handle this, but it’s throwing a 409 Conflict every time.
Here’s the snippet:
api_instance = genesyscloud.users.UsersApi(api_client)
try:
api_instance.delete_user(user_id, force=True)
except Exception as e:
print(f"Error: {e}")
The error message just says ‘User is associated with other resources’. I’ve already cleared their skills and removed them from all queues via the UI. What am I missing?
might be worth checking if that user is still assigned as an owner on any other resources. the 409 usually means there’s a foreign key constraint holding it up. it’s not just about the user record itself.
studio scripts handle this by checking dependencies first, but since you’re using the python sdk, you’ll need to query the potential blockers before hitting delete. try this flow:
import genesyscloud
from genesyscloud.users import UsersApi
api_instance = UsersApi(api_client)
# 1. Check for queue ownership
queues_api = genesyscloud..QueuesApi(api_client)
queues = queues_api.get_routing_queues()
for q in queues.entities:
if q.owner and q.owner.id == user_id:
print(f"User owns queue {q.id}. Reassign or remove owner first.")
return
# 2. Check for group membership
groups_api = genesyscloud.organizations.OrganizationsApi(api_client)
# Note: You might need to check specific groups if they are admins of them
# A common blocker is being the sole admin of a group or organization unit
# 3. If clear, attempt delete with force
try:
api_instance.delete_user(user_id, force=True)
print("User deleted successfully.")
except Exception as e:
print(f"Failed to delete: {e}")
the force=True flag only handles soft-deleted interactions and active sessions. it doesn’t untangle ownership ties. if the user is an owner of a queue, a group, or a wrap-up code, the api will reject the deletion to prevent orphaned resources. you have to manually reassign those ownerships or remove the user from them first.
also, double-check if the user is part of an organization unit where they hold an admin role. if they’re the last admin, you can’t delete them until you add another. it’s a common gotcha. check the response body of the 409 error too. it often lists the specific resource id causing the conflict. that saves a lot of guessing.