Freshdesk Notifications Not Working: Fixes
When a Freshdesk notification goes missing, nothing errors out and nothing lands in a dead-letter queue — the email simply never arrives, and the first you hear of it is an agent who "didn't know the ticket existed" or a customer who complains they never got a reply confirmation. Freshdesk has two entirely separate notification systems, one for your agents and one for your requesters, and each has its own on/off toggles, its own recipient logic, and its own quiet ways of dropping mail. Most "notifications not working" reports trace back to a handful of predictable causes: a toggle that's off, a ticket with no assignee, an automation quietly overriding the default, or plain deliverability. This guide walks through where each notification lives, why it silently fails, and how to fix it — agent side and requester side.
Agent vs requester: two systems, not one
The single most useful thing to understand is that Freshdesk splits notifications into distinct audiences, and a fix for one does nothing for the other. Under Admin → Workflows → Email Notifications, Freshworks' Configure email notifications documentation lays out four tabs:
- Agent Notifications — alerts your team about new tickets, assignments, requester replies, notes, and (on Pro and above) SLA reminders and violations.
- Requester Notifications — the emails your customers receive: a ticket-created confirmation, "an agent has replied," "your ticket was solved/closed," plus account emails like activation and password reset.
- CC Notifications — what CC'd users get when an agent creates a ticket or adds a public note.
- Templates — the reply templates that wrap those emails.
So "agents aren't getting notified" and "customers aren't getting notified" are two different investigations. Start by identifying which audience is affected — it narrows the problem immediately.
The single biggest trap: only "New ticket created" notifies multiple agents
Here's the detail that catches almost everyone. On the Agent Notifications tab, only the New ticket created rule lets you name a list of agents who should be alerted. Per Freshworks' own why am I not getting new-ticket notifications article, the emails go only to "the agents whose names are added under the Notify agents section." If your name isn't in that box, you get nothing — even if the toggle is on.
For every other agent notification — Ticket assigned to agent, Requester replies to ticket, Note added — there is no recipient list at all. The notification goes to the assigned agent and nobody else. This produces two of the most common silent failures:
- Nobody is in the Notify agents list, so new-ticket alerts reach no one. Fix: open Admin → Workflows → Email Notifications → Agent Notifications → New ticket created, confirm the toggle is on, and add each agent who should be alerted.
- The ticket has no assignee, so "Requester replies to ticket" and "Ticket assigned to agent" have no recipient to send to. An unassigned ticket in a shared queue can sit silently because there is literally no agent for Freshdesk to notify.
A fix checklist for agent notifications
Work through these in order — they're roughly sorted by how often they're the culprit.
- Is the toggle on? Each rule on the Agent Notifications tab has an independent switch. A recent admin change can flip one off without touching the others.
- Is the agent in the "Notify agents" list? Applies specifically to New ticket created. No name in the box, no email.
- Does the ticket have an assignee? Assignment-dependent notifications (assigned-to-agent, requester replies, note added) only fire to the person the ticket is assigned to. Unassigned tickets in a group produce no per-agent email unless you use Ticket assigned to group / Ticket unattended in group.
- Is an automation overriding the default? If a rule under Admin → Workflows → Automations already sends a custom notification on the same trigger, teams sometimes disable the default to avoid duplicates — and then forget. Check your Ticket Creation and Ticket Update automations.
- Is the agent both an agent and the requester? Freshdesk deduplicates to avoid emailing you about your own action, which means an agent who is also the requester on a ticket may not receive the assignee notification. The Freshworks community documents this and the workaround is a custom Automation on Ticket Updates that notifies the assignee explicitly.
- Deliverability. Check spam/junk folders and, if you use a custom mailbox, your DKIM/SPF setup. A notification that Freshdesk sends but the mail server quarantines looks identical to one that was never sent.
A fix checklist for requester notifications
Requester emails fail for overlapping-but-different reasons.
- Is the specific rule enabled? On the Requester Notifications tab, "New Ticket Created," "Agent adds comment to ticket," "Agent solves the ticket," and "Agent closes the ticket" each have their own toggle. Turning off "Agent solves the ticket" is a common way teams accidentally stop resolution confirmations.
- Is an automation handling it instead? If a Ticket Creation automation sends a branded acknowledgement, the default "New Ticket Created" requester notification is often disabled so customers don't get two emails. That's by design — but confirm the automation is actually still firing.
- Public vs private note. Requesters are only notified about public replies. If an agent adds a private note thinking it's a reply, the customer never hears anything — a workflow problem that masquerades as a notification bug.
- Deliverability and the "no-reply" trap. Requester emails come from your support address; if that address's authentication is misconfigured, corporate mail filters silently drop them.
Where each notification actually goes — a quick decision table
| Notification | Tab | Who receives it | Common silent-drop cause |
|---|---|---|---|
| New ticket created | Agent | Only agents in the Notify agents list | Nobody added to the list |
| Ticket assigned to agent | Agent | The assigned agent only | Ticket unassigned |
| Requester replies to ticket | Agent | The assigned agent only | Ticket unassigned |
| Note added to ticket | Agent | The assigned agent only | Private note; or unassigned |
| SLA reminder / violation | Agent (Pro+) | Nominated agent/manager | Not on a plan that supports SLA rules |
| New Ticket Created (confirmation) | Requester | The requester | Overridden by a creation automation |
| Agent solves / closes ticket | Requester | The requester | Rule toggled off |
The pattern to internalise: agent-side failures are usually about who the assignee is; requester-side failures are usually about which rule is on and whether an automation took over.
The honest limits of Freshdesk's notification system
Freshdesk's notification engine is doing exactly what it's designed to do, and it's genuinely reliable at it: deterministic rules, clear toggles, per-audience separation. When it "fails," it's almost always configuration, not a bug. But it's worth being clear about what the system fundamentally is — and isn't.
It is a routing layer for events, not an intelligence layer. It can tell an agent a ticket arrived; it can't read that ticket, understand the customer's problem, and act on it. Notifications also can't compensate for structural gaps: an unassigned ticket in a busy shared queue generates no per-agent email by design, so if your routing is weak, notifications won't rescue it. And because the assignee is the linchpin for most agent alerts, teams that rely on manual triage inherit a race — the ticket is quiet until someone picks it up, and the notification that would have prompted them only fires after they do.
That gap — between "an event happened" and "someone actually handled it" — is where an AI agent layer fits, and it's worth weighing the build-versus-buy tradeoff honestly before adding one. The broader category of AI agents for customer service exists to do the part a notification can't: comprehend the ticket and respond. Macha is one such layer, and it runs on top of the Freshdesk you already use through a native connector — it does not replace Freshdesk, its notification rules, or its automations. You connect Macha to Freshdesk with your subdomain and API key, and it reads and writes the same tickets your notifications track. Instead of only alerting a human when a new ticket lands, it can draft or post a grounded first reply itself — the kind of consistent, on-brand response you'd otherwise reach for a canned response to approximate — and it can look up order or account status through a custom tool that turns a REST API into something the agent can call. If you want to see how that sits alongside your existing rules, automating Freshdesk with AI walks through the connect-and-configure flow.
The clean division of labour: keep Freshdesk's notifications as the source of truth for what happened and who to tell, and layer an agent on top for the part a notification can't do — actually reading and answering the ticket. Macha's connector is for Freshdesk specifically (not Freshchat, Freshservice, or Freshcaller), and credits are consumed per AI action rather than per resolution — the pricing page breaks that down.
FAQ
Where do I configure email notifications in Freshdesk? Go to Admin → Workflows → Email Notifications. You'll find four tabs — Agent Notifications, Requester Notifications, CC Notifications, and Templates — each with its own on/off toggles and editable subject lines and message bodies.
Why am I, as an agent, not getting new-ticket notifications? Two reasons account for almost all cases: the "New ticket created" toggle is off, or your name isn't in the Notify agents list for that rule. That rule is the only agent notification that supports a list of named recipients — for every other agent notification, only the assigned agent is emailed.
Why do agent notifications work for some tickets but not others? Most agent notifications (assigned-to-agent, requester replies, note added) go only to the ticket's assigned agent. If a ticket is unassigned or sitting in a shared group without an owner, there's no recipient, so no email is sent — even though the rule is enabled.
Why did my customer not get a reply notification? Check that the relevant Requester Notification rule is enabled, that the agent sent a public reply rather than a private note, and that no Automation has replaced the default notification. Also check the requester's spam folder and your support address's email authentication.
Can I add AI to Freshdesk without changing my notification setup? Yes. Macha connects to Freshdesk as a native connector and runs on top of your existing help desk, notifications, and automations — it doesn't replace them. It helps close the gap between an alert firing and a ticket being handled by drafting or sending a grounded first reply, while Freshdesk stays the system of record for what happened and who to notify.
Tired of chasing notifications that never arrived? Start a free trial of Macha and connect it to your Freshdesk in minutes.
Add AI agents to your Freshdesk
Macha resolves tickets end to end on Freshdesk — no migration, no code.
Zendesk
Freshdesk
Gorgias
Front
Shopify
Stripe
Slack
Notion
Google Workspace
Confluence

