Deactivating a Freshdesk Agent

Someone has left. To deactivate a Freshdesk agent, reassign their tickets and keep the history are three different actions, and only one is the button you're looking at.

Deactivate a Freshdesk agent, or delete them

Two different operations that people use interchangeably, wrongly.

Deactivating an agent switches off their access. They can't log in. Their name still exists in the system, their past replies still show their name, and reports covering last quarter still attribute their work to them. Crucially, the seat they occupied is released back to your subscription so you can assign it to someone else.

Deleting an agent removes the agent record. What that does to the historical trail is the part worth being careful about, because attribution on old conversations is exactly the thing you cannot rebuild later.

The rule is easy. Deactivate people. Delete only genuine mistakes, like the account you created twice during onboarding with a typo in the address.

What happens to their tickets

Nothing. That is the answer, and it is the answer that bites teams.

Deactivating an agent does not reassign their open tickets. Those tickets keep sitting there with a departed person name in the assignee field. They don't appear in the unassigned queue, because technically they have an assignee. They do not trigger the escalation rules you built for unowned work, for the same reason.

A ticket assigned to someone who no longer works here is the quietest failure in support. Nobody sees it until the customer chases.

So the order of operations matters. Before you deactivate anyone, filter tickets by assignee, select everything not yet closed, and bulk reassign it. To a group, not to another individual, because the next person might leave too. Then deactivate.

If you have already deactivated someone and skipped that step, you can usually still filter by their name in the ticket list and reassign from there. Check yours today. Most teams find at least one.

Freeing the seat, and the billing question

Deactivation is what releases the licence. Simply asking someone to stop logging in does not, and I have seen an account paying for four ghost agents for eleven months because nobody made that connection.

The freed seat becomes available to assign to a new agent. What it does to your bill is a separate question and depends on how your subscription is set up, since a seat you stop using isn't automatically a seat you stop paying for until the count is adjusted. Check your billing screen and the current Freshworks docs on reducing agent count mid-cycle, because the annual and monthly behaviours differ.

If the departing person was an occasional agent rather than a full seat, none of this applies. There is no licence to reclaim, just a pool balance they will stop drawing from.

An offboarding checklist that works

Run it in this order. The order is the whole point.

Reassign open tickets to the owning group, not to a person. Include pending and on-hold ones, not just open.
Check automations and rules for their name. Assignment rules and escalation rules that point at a named human break silently.
Reassign anything they own outside tickets. Scheduled reports, dashboards, shared views, integration credentials created under their account.
Deactivate the agent to cut access and release the seat.
Revoke API keys created under their login, which is the step everyone forgets and the one a security auditor asks about.
Adjust your subscription count if you're not backfilling the role.

Five minutes if you do it on the day. A fortnight of archaeology if you do it in three months.

The reactivation case

People come back. Contractors return for a second project, someone leaves and rejoins, a seasonal agent works two Christmases in a row.

That's a decent argument for deactivating rather than deleting even when you think the departure is permanent. Reactivating a deactivated agent restores a person who already exists, with their history intact. Recreating a deleted one gives you a new person who happens to share a name with the one in your old reports.

Storage of a deactivated record costs you nothing. Rebuilding attribution costs you an afternoon and never quite works.

FAQ

Frequently asked questions

What does a proper offboarding look like?

Reassign, then deactivate, then check the seat count. Freshdesk offboarding done in that order keeps the history; to Freshdesk remove agent records entirely you delete, and that loses attribution on their old tickets.

Does deactivating a Freshdesk agent free up the seat?

Yes, deactivation releases the licence so it can be assigned to someone else. Whether your invoice drops depends on how and when you adjust the agent count on your subscription, so check your billing settings.

What happens to tickets assigned to a deactivated agent?

They stay assigned to that agent. They do not move to the unassigned queue and they don't trigger unowned-ticket escalations. Reassign open tickets to the group before you deactivate anyone.

Should I delete an agent instead of deactivating them?

Almost never. Deactivation keeps historical attribution on past conversations and reports, and lets you reactivate the same person later. Delete only duplicate or mistaken accounts.

Can a deactivated agent be reactivated?

Yes, provided you have a free seat to give them. Their record, history and past ticket attribution come back with them, which is one of the better reasons to deactivate rather than delete.

Do I need to remove their API keys separately?

Yes. Treat any API key or integration credential created under a departing agent login as a separate revocation step in your offboarding checklist.

Clean queue, clean handover

Before you reassign a departed agent workload, it is worth removing the duplicates in it. Ticket Merger finds and merges them automatically.

Start free trial

14-day free trial. No credit card required.