What happens to a user’s work when they leave?

Short answer: Atender preserves everything but reassigns nothing. When you deactivate a user, their history stays intact and their work-in-progress sits where they left it. You handle the reassignment yourself — the system isn’t going to do it for you.

What deactivation does immediately

The moment you flip a user to inactive:

• They can’t log in. All sessions are signed out.
• They drop out of routing. Voice calls and task routing stop ringing them.
• They move to the Inactive Users tab. They no longer show up in default user pickers.

What stays in place — this is the surprising part:

• Conversations they were assigned to stay assigned to them. The conversation record shows their name as the agent even though they can’t act on it.
• Drafts they were writing stay attached to those conversations. Untouched.
• Internal notes and comments they wrote remain attributed to them.
• Team memberships stay intact. The Inactive user is still listed as a team member.
• Mentions and @-tags pointing at them stay there. They won’t see them (they can’t log in), but they’re not stripped from the conversation.

This is intentional. Audit trails matter — you can always look back and see who handled what. But it means you have to plan the handover yourself.

What you should do before deactivating

For a planned departure, run through this checklist:

1. Reassign their open conversations. Filter the inbox to Assigned to {their name}, bulk-reassign to another agent or to Unassigned. Don’t leave conversations stranded with a deactivated owner.
2. Pick up their snoozed conversations. Snoozed conversations come back into the inbox eventually. If they’re tagged for a deactivated user, the inbox will reopen them as orphaned. Filter snoozed conversations by agent before they wake up.
3. Resolve scheduled callbacks and follow-ups. If they had Auto-callback at 10am tomorrow-style scheduled actions, those still fire. Reassign to someone who can take the call.
4. Change their Owner role first. Before an administrator deactivates a sole Owner from Settings → Users, promote another user to Owner first, then change the departing Owner’s role. The system refuses to deactivate any Owner: “Cannot deactivate an owner. Change their role first.”
5. Hand off their drafts. Drafts they were composing won’t go anywhere on their own. If they were in the middle of a complex reply, copy the draft content out before deactivating, then continue from a new agent’s session.

A departing person can also initiate their own account-deletion request in the app. That immediately removes their access, and if they were the only Owner it may leave the workspace with nobody able to administer it. Ownership handover is still strongly recommended before they leave.

For unplanned departures (sudden leave, fired, etc.) you’ll do these steps after deactivation instead of before — it works the same way, just under more pressure.

What about their team memberships?

Deactivated users remain in their teams’ member lists. This doesn’t break anything — routing skips them because they’re inactive — but the team’s headcount is misleading until you remove them.

To clean up, open Settings → Teams, edit each team they belonged to, and remove them from the member list. See Add or remove team members.

Is there a “transfer all my work to X” button?

Not as a single workflow, no. Atender doesn’t have a bulk reassignment that says “everything currently owned by Alice → now owned by Bob, including future events.” You assemble it from:

• Inbox bulk-actions for active conversations
• Manual cleanup of team memberships
• Optional: an automation rule you build temporarily — e.g., If Assignee was Alice → Reassign to Unassigned. Useful when the departing user had a large book of work.

For most departures the manual flow is fine. For mass offboardings (acquired team being onboarded under a new structure), the automation route is faster.

What about deletion?

Deletion is a separate, irreversible step that’s additional to deactivation. It removes the user’s membership and replaces their name in audit trails with “Deleted user.” Conversations they were involved in stay; the attribution becomes anonymous.

Most departing users don’t need to be deleted — deactivation is enough. Reach for deletion only when there’s a specific reason (compliance request, account created in error). When in doubt, deactivate and revisit later.

Compliance angle

Some tenants are required to retain user records for a fixed period (typically 1–7 years depending on jurisdiction and industry). Deactivation preserves the record without granting access; that’s usually what compliance teams want. Confirm with your legal counsel before deleting, especially for users who handled regulated transactions (financial, healthcare, etc.).

A common pattern: deactivate immediately on departure, keep the record for the retention window, delete after the window closes if required.

See also

• What are Users?
• Deactivate or reactivate a user
• Change a user’s role — sometimes “they’re leaving” means “they’re moving to a different role”
• Add or remove team members