Freshdesk Email Notifications

Freshdesk email notifications serve two audiences with opposite needs from one settings screen, and a handful of options quietly send your customers the same message twice.

The two families of Freshdesk email notifications

Freshdesk separates agent notifications from requester notifications, and they should be tuned by completely different logic.

Agent notifications tell your team something happened: a ticket was assigned to them, a customer replied, a ticket was escalated, someone mentioned them in a note.

Requester notifications tell the customer something happened: their ticket was received, an agent replied, the ticket was resolved or closed.

The mistake is treating them as one problem. Agents drown when they get everything. Customers get suspicious when they get too little. Different failure modes, different fixes.

Agent notifications, and how to cure the fatigue

The symptom is easy to spot: an agent has a mail rule that files every Freshdesk message into a folder they never open. Once that exists, notifications have stopped working entirely, including the ones that mattered.

The rule I would apply is simple. Notify on action required, not on activity.

Keep: assigned to me, customer replied to my ticket, I was mentioned, escalation or SLA breach.
Turn off: a ticket was created somewhere in the system, a ticket I don't own was updated, a note was added by someone else on a ticket I am not on.
Question hard: any "for your awareness" notification. Awareness is what the queue view is for. If someone needs to watch a category of ticket, give them a saved view and a habit, not an email every time.

Then decide where notification actually belongs. Assignment and breach alerts are often better in a chat channel than in a mailbox, because a mailbox is where things go to be triaged later and an escalation is not a later problem.

One structural fix worth more than any toggle: route to groups rather than individuals, so notifications are shaped by what someone owns rather than sprayed at everyone.

Requester notifications: what customers should get

Fewer than most setups send, but each one carrying real information.

Acknowledgement on arrival, with a realistic expectation of when a human will reply. This is the highest-value email in the whole system. It's what stops the customer emailing again to check you got it.
Agent reply, obviously.
Resolution, with a clear way to say it isn't actually fixed.

Everything else is optional and most of it's noise. Notifying a customer that their ticket status changed internally, or that it was reassigned, tells them nothing they can act on and trains them to ignore your emails.

Two content details that matter more than the settings. Put the actual reply text in the email rather than a "log in to view" link, because forcing a portal login to read one sentence generates more contacts than it prevents. And check the from address, the reply-to and the display name on your templates, since a mismatch there's what makes replies fail to thread and turns one conversation into several tickets.

The settings that cause duplicate emails

This is the complaint that arrives as "your system sent me the same email three times", and it's almost always one of these five.

An automation that duplicates a built-in notification. Somebody builds a rule that emails the requester on ticket creation, forgetting the standard acknowledgement already does exactly that. Two emails, seconds apart, near-identical. Check your creation rules against the default notifications before adding any.
Overlapping automation rules. Two rules whose conditions both match, each sending an email. Rule order and the option to stop processing further rules exist precisely for this, and both are commonly left at defaults.
CC and reply-all behaviour. The requester is also in the CC list, so they receive the agent reply once as the requester and once as a copied party. Anyone who has been copied into a thread can end up on the ticket, and each one is another recipient of every subsequent message.
Multiple forwards into the same helpdesk. help@ and support@ both forward in, and a customer who mails one while being copied on the other produces two tickets, each generating its own acknowledgement. The customer sees duplicates because there genuinely are duplicates.
A forwarding loop. The old mailbox forwards to Freshdesk, and the Freshdesk outbound reply lands back in the old mailbox, which forwards it in again. This one escalates fast and it's worth checking whenever you change email routing.

The diagnostic is always the same. Get the raw headers of the two emails the customer received. They will tell you whether it's one ticket notified twice, which is a rules problem, or two tickets each notified once, which is a routing problem. Those need completely different fixes and guessing wastes an afternoon.

A twenty minute audit

Do this once and then once a year.

List every enabled requester notification and ask what the customer does differently on receiving it. Turn off anything with no answer.
Read every automation that sends email and check none of them overlaps a built-in notification.
Send yourself a real ticket from an outside address and count the emails you receive. Anything above two before an agent has typed a word is a problem.
Ask two agents whether they have a mail rule hiding Freshdesk notifications. That answer tells you more than the settings screen does.

Automation rule design is where most of this gets fixed, and the patterns are covered in the automations guide.

FAQ

Frequently asked questions

Which Freshdesk email settings cause duplicate emails?

Two in particular: forwarding that also leaves a copy in the original mailbox, and an agent notification that fires on both create and update. Freshdesk duplicate emails almost always trace back to one of those Freshdesk email settings.

Why do Freshdesk email notifications arrive twice?

Usually an automation duplicating a built-in notification, two overlapping rules both sending mail, or the requester also sitting in the CC list. Check the raw headers to see whether it's one ticket notified twice or two separate tickets.

Can I turn off notifications for individual agents?

Notification rules are configured at the account level, and agents can additionally manage some of their own preferences. The structural fix is routing to groups so people only get notified about what they own.

Should the acknowledgement email be turned off?

No. It's the notification that prevents the most follow-up contacts. Make it specific about when a human will reply rather than removing it.

Why do replies create new tickets instead of threading?

Usually a from address, reply-to or display name mismatch in your email settings, or a stripped message identifier. Send a test from an outside address and reply to it to confirm threading works.

Should notifications go to email or chat?

Escalations and SLA warnings work better in a chat channel, where they're seen now. Assignment and customer replies are fine in email. Sending everything to both is how people learn to ignore both.

When two tickets are the real cause

Duplicate emails often mean duplicate tickets. Ticket Merger detects and merges them automatically, so the customer gets one thread and one answer.

Start free trial

14-day free trial. No credit card required.