We are running into a state management issue with the genesyscloud_user resource. The business requirement is to remove a terminated agent from the active directory but retain all historical interaction data (calls, chats, emails) for compliance.
The documentation suggests using the DELETE /api/v2/users/{userId} endpoint to “soft delete” the user. This seems perfect because it keeps the interaction history intact while removing the user from active provisioning.
However, if we run a terraform destroy on the corresponding resource, the provider attempts to delete the user via the API. The problem is that Terraform then removes the resource from the state file entirely. If we ever need to reconcile or if the deletion fails mid-execution, the state is out of sync with the actual API state (deleted but not destroyed in Terraform’s eyes, or vice versa).
I tried to workaround this by using terraform import after the API deletion, but that just pulls the user back into an active state if the API allows it, or fails if the user is truly gone.
Is there a recommended pattern for managing this? Do we use a lifecycle block to ignore changes, or is there a specific API parameter we are missing that tells Genesys to keep the user object but mark it as inactive without triggering a hard delete that breaks the Terraform state?
Here is the current resource definition:
resource "genesyscloud_user" "agent_user" {
name = var.agent_name
email = var.agent_email
division_id = var.division_id
# Attempting to prevent hard delete
lifecycle {
prevent_destroy = true
}
}
When prevent_destroy is set, we can’t remove the resource at all. If I unset it, Terraform calls DELETE /api/v2/users/{id} and then removes the state. We lose the ability to track that this user was ever provisioned by us.
We need a way to call the API to deactivate the user without Terraform trying to manage the lifecycle of that deletion. Is there a separate endpoint for “deactivate” that doesn’t remove the resource ID?