Deactivate or delete an agent while preserving support coverage

Agent offboarding is both an access decision and an operational handoff. Removing an account does not decide who will answer its customers, own its open cases or cover its queue. Review those responsibilities first, then choose the appropriate access action. Use Active for an intended temporary deactivation; reserve Delete agent for a deliberate removal whose consequences have been reviewed.

Choose the action that matches the situation  ·  Review work and dependencies before changing access  ·  Temporarily deactivate an agent  ·  Delete an agent only after the handoff is ready  ·  Verify the operational result  ·  Example: a specialist leaves during a customer escalation  ·  Troubleshoot access and offboarding outcomes

Choose the action that matches the situation

The organization should define who approves offboarding and who confirms customer coverage. This guide describes the product steps; it does not replace those business decisions.

Review work and dependencies before changing access

1. Identify the exact agent, account and intended action. Compare the profile identity rather than relying only on a display name.
2. Review open cases and unresolved customer commitments. Assign a receiving owner through the normal case workflow and verify the saved result.
3. Review queues, team membership, schedules, escalation responsibilities and specialist coverage. Confirm who will monitor new incoming work.
4. Review relevant tasks, planned appointments, asset assignments and ongoing internal handoffs. Record the next action and its owner.
5. Review notification destinations and integrations that depend on this identity using their own administration procedures. Removing an agent should not leave a failure mailbox or integration without an owner.
6. Confirm the operational handoff with the responsible support lead before the access action.

For a complex account, a useful handoff includes the customer impact, last action, unresolved dependency, next promised update and the person who will deliver it. A list of case numbers alone may not tell the receiving agent what needs attention first.

Temporarily deactivate an agent

1. Open Settings → Organization → Agents and open the intended agent profile.
2. Select the profile’s Settings tab.
3. In Login & access, turn Active off when temporary deactivation is the approved action.
4. Choose Save profile and verify the saved state. The Agents grid’s Active value is a display, not the editing toggle.
5. Confirm work coverage separately. Follow the organization’s security process for any additional session/access requirements.

The control requires authority to edit that agent’s active state. Restoring Active later can also be limited by licensing and other account conditions. Do not promise that reactivation will always be available without a review. Active, Online/Away presence and Out of office describe different concerns.

Delete an agent only after the handoff is ready

1. Open Settings → Organization → Agents. Confirm the exact agent identity and that deletion is the intended action.
2. Use the list’s delete control, identified as Delete this agent?.
3. Read the confirmation: This process is not reversible. Are you sure you would like to delete this agent? Stop if the record or intent is uncertain.
4. Choose Delete agent only when the reviewed offboarding action is authorized.
5. Verify the result in the Agents list and check that the receiving owners and coverage arrangements remain correct.

Deletion requires the applicable page editing authority and Alter other agent profiles permission. The Core delete route is blocked in sandbox. If an action is unavailable, resolve the permission or environment through normal administration rather than using an unrelated route.

Verify the operational result

• Confirm that the intended agent’s access/profile state changed as expected.
• Open representative transferred cases and verify the new owner, active service commitments and next customer update.
• Check queue and escalation coverage under the responsible team’s normal operating view.
• Verify integrations or notification responsibilities that had depended on the departing agent using their own status and configuration evidence.
• Record the completed handoff and unresolved dependencies in the approved operational location.

Avoid deleting and immediately provisioning a same-named replacement as a presumed undo. Identity, account association and licensing rules still apply, and the same display name does not establish continuity with the deleted identity. Ask the authorized administrator/support process to determine the appropriate recovery or replacement path.

Example: a specialist leaves during a customer escalation

A specialist owns an unresolved product issue involving several contacts at a major customer. Before access is removed, the support lead assigns a receiving owner, records the technical findings and next update time, and checks the escalation queue’s coverage. The receiving owner verifies the case and customer communication plan.

The administrator then applies the approved access action. The lead checks the saved case assignment again afterward. This makes the handoff observable: the customer’s next update has a named owner rather than depending on whether the departing agent still appears in a list.

Troubleshoot access and offboarding outcomes

Continue learning

• Configure agent roles and division access
• Hand over cases with clear ownership
• Plan absence and support coverage
• Configure queue membership and assignment
• Keep escalation ownership accountable