How to connect Freshdesk to Slack using its dispatch and business hours

To connect Freshdesk to Slack, let Freshdesk's own rules decide which tickets matter, and let the integration decide who hears about them and what the message says. Freshdesk already classifies, reacts and measures deadlines before a person sees a ticket. An integration that computes its own conditions will disagree with Freshdesk and lose the team's trust.

Key takeaways

• Use Freshdesk's dispatch, observer and supervisor rules to select tickets, and use the integration for routing and message text.
• Read the due-by time on each ticket instead of computing deadlines, because Freshdesk already applies business hours and calendars.
• Escalate to people outside the helpdesk with a short summary in Slack, and write the reply back as a private note.
• Send poor satisfaction ratings to the team lead on the day they arrive, with the customer's comment.
• Make alerts idempotent and skip tickets that are pending the customer.

What we'll cover

• Which three rule types already run?
• Why do business hours change every calculation?
• How do you build it with CodeWords?
• Which messages build on existing rules?
• How do you escalate out of the helpdesk?
• How do you show agent workload?
• How do you keep groups and routing in step?
• How do you handle satisfaction ratings?
• How do you keep the integration reliable?
• What are the limits?
• What should you set up first?
• Frequently asked questions

Which three rule types already run?

Freshdesk runs dispatch, observer and supervisor rules, plus SLA policies. Each is a hook you can use instead of reimplementing it.

Rule	When it runs	Use it for
Dispatch rules	Once, when a ticket arrives	Setting priority, group, agent and tags
Observer rules	On a change, such as a reply, status change or reassignment	Triggering an outbound notification
Supervisor rules	On a schedule, over tickets matching conditions	Anything about staleness ("nothing happened for too long")
SLA policies	Continuously, per priority and group	Response and resolution targets on a business calendar

Let the support team keep maintaining the rules. Let the integration pick the audience and write the message.

Why do business hours change every calculation?

Business hours change every calculation because SLA targets run on business calendars, not the clock. A ticket raised at five on Friday with a four-hour target is not late on Saturday morning. A locally computed alert ignores this and disagrees with Freshdesk.

• Calendars differ per group. Two regional teams have different clocks, so one global calculation is wrong for at least one of them.
• Holidays are configured. A calculation that ignores them alerts through a public holiday, which teaches people to mute the channel.
• Some policies run around the clock and others do not, often in the same helpdesk.
• Read Freshdesk's own due-by times. They are on the ticket and already account for all of the above, so the integration and the helpdesk always agree.

How do you build it with CodeWords?

Build it in CodeWords by describing the alert to Cody, the automation builder, in plain language. CodeWords connects to 3,000+ integrations (CodeWords pricing page, 2026), and you make each connection once and reuse it.

1. Open CodeWords and start a new automation.
2. Describe to Cody which tickets, what condition and who should be told.
3. Authorize the connection to Freshdesk with an API key for a dedicated agent account, and to your Slack workspace.
4. Describe the exceptions: a ticket already resolved, a ticket paused pending the customer, an agent who is away.
5. Test against a sandbox and a test channel before anything reaches the support team.

You describe the outcome, and Cody builds, connects and deploys it. The Free plan costs $0, Pro costs $39 per month and Business costs $100 per month (CodeWords pricing page, 2026). Details are on the pricing page.

Which messages build on existing rules?

The messages that work best are triggered by a tag or change that a Freshdesk rule produces. A supervisor rule adds a tag and the integration watches for it. The support team controls the condition in Freshdesk, and you control the message.

• Approaching the due-by time. Send Freshdesk's own value to the assigned agent before the time passes.
• A ticket dispatch could not classify. It lands in a default group and sits there because nobody owns that group.
• A high-priority ticket unassigned past a short threshold. Priority without an owner is the combination that goes wrong.
• A ticket reopened after resolution. Tell the agent who resolved it, because a reopen usually means the fix did not work.
• A customer response on a ticket waiting on them. The agent picks it up promptly instead of at the next queue sweep.

How do you escalate out of the helpdesk?

Escalate by posting a short summary of the ticket to a Slack channel with the right people, then writing the reply back to the ticket as a private note. Agents need input from people who do not use Freshdesk, such as engineers, account managers and finance, and adding them as agents is neither practical nor cheap.

• Post the question with the relevant detail extracted, instead of only a ticket link. A link is a request to read a thread.
• Say which customer and how urgent, because the person deciding whether to interrupt their work needs both.
• Write the reply back as a private note, so the conversation is on record and the next agent sees the reasoning.
• Route by topic to the right channel, and time out to a named person if nobody responds.
• Count what is escalated and about what. Recurring topics point to a documentation gap, and the list is the specification for filling it.

How do you show agent workload?

Show workload by posting open tickets per agent, and report imbalance instead of raw counts. Open tickets per agent are visible in Freshdesk, but nobody looks at them during a busy day, which is when they matter.

• Report imbalance. One agent with three times the queue of another is a routing problem, and the number makes it a two-minute fix.
• Include tickets approaching due-by per agent. This is the urgent half of the workload.
• Post at shift start, when somebody can act, not at the end of the day.
• Send it to the team lead, not the whole team. A public workload ranking changes behavior in ways that improve the numbers and worsen the support.

How do you keep groups and routing in step?

Keep groups and routing in step by checking dispatch rules against your directory on a schedule. Dispatch rules reference groups and agents that change as people join and leave. A rule that points to a departed agent stops assigning, and tickets accumulate in a queue nobody watches.

• Report tickets in the default group weekly, since unclassified work collects there.
• Report groups with no active agents. This happens after a reorganization and leaves a queue with no owner.
• Check the rules periodically. Nothing in Freshdesk tells you a rule has become a dead end.

How do you handle satisfaction ratings?

Route a poor satisfaction rating to the agent's lead on the day it arrives, with the ticket and the customer's comment. Freshdesk collects customer satisfaction responses, but they land in a report nobody opens. A week later a rating is a statistic. On the day, it is a conversation that can still involve the customer.

• Include what the customer wrote. The comment is the useful part, and the score alone does not say why.
• Do not route it to the agent automatically. A poor rating with no context is demoralizing, and the lead can decide whether and how to raise it.
• Watch for patterns. One poor rating is noise, and three on the same topic point to a product or documentation problem.
• Share the good ones in the channel. Support teams hear about failures constantly and successes rarely.
• Report the response rate too. A score calculated from four responses out of two hundred tickets does not measure anything.

How do you keep the integration reliable?

Keep it reliable by reading due-by values, making alerts idempotent and reporting what the automation did.

• Read Freshdesk's due-by values instead of computing deadlines.
• Make alerts idempotent, keyed on the ticket and the condition, so a ticket does not alert repeatedly for the same reason.
• Respect ticket status. A ticket pending the customer is not late in the way an open ticket is, and alerting on it is noise.
• Map agents to Slack users from your directory, and report failures instead of dropping messages.
• Report the outcome: alerts sent, escalations raised and notes written back.

What are the limits?

Five limits apply: rate limits, plan-dependent features, copied ticket content, custom fields and webhook delivery.

• Rate limits apply per account and depend on your plan, so scanning many tickets needs pacing. Check Freshdesk's API documentation for your plan.
• Some automation features depend on plan, so the rule types available differ between tiers.
• Ticket descriptions contain whatever the customer wrote. Slack holds a separate copy, so channel membership matters.
• Custom fields vary per helpdesk, so anything that reads one must handle its absence.
• Webhooks from automation rules can be delivered more than once, which is why idempotency matters.

What should you set up first?

Set up an approaching due-by alert first, using Freshdesk's own value and sent to the assigned agent before the deadline passes. It agrees with the helpdesk by construction, needs no deadline arithmetic and catches the ticket while there is time to act.

Two habits make the difference. Use the due-by time on the ticket instead of calculating from age, since business hours and per-group calendars make those two numbers very different. And skip tickets pending the customer, because alerting on them is the fastest route to a muted channel.

Frequently asked questions

Should I compute SLA deadlines myself?

No. Freshdesk's due-by values already account for business hours, per-group calendars, holidays and the applicable policy. Computing your own deadlines guarantees the integration and the helpdesk eventually disagree, and the helpdesk is the one the team trusts. Read the due-by value from the ticket instead.

How should conditions be defined?

Define conditions in Freshdesk with supervisor or observer rules, and have the integration react to the tag or change they produce. The support team can then adjust the condition without touching the automation, which keeps the setup maintainable and keeps the logic in one place.

Why do alerts fire on a public holiday?

The calculation ignored the business calendar. Holidays are configured in Freshdesk and reflected in due-by times, which is another reason to read those values instead of computing from ticket age. Switching to the due-by time removes the problem without any extra holiday logic.

How do agents get help from people outside Freshdesk?

Post the question with the key details into a channel that has the right people, then write the reply back onto the ticket as a private note. Adding engineers as agents is neither practical nor cheap, so this route keeps the record in Freshdesk without extra seats.

What about the default group?

Report it weekly. Tickets that dispatch rules could not classify land in the default group and sit there, because a group that belongs to nobody in particular is a queue nobody sweeps. A weekly report gives the team a short list to classify.

Should workload reports be public?

No, send them to the team lead. A public ranking of open tickets per agent changes behavior toward closing tickets instead of resolving them, which improves the number and not the support. The lead can act on imbalance without turning the report into a scoreboard.

Why did a dispatch rule stop assigning?

The rule probably references an agent or group that no longer exists. Nothing in Freshdesk reports this, and tickets quietly accumulate unassigned. Checking dispatch rules against your directory on a schedule is the only way to catch the problem before customers wait.

What should happen when a customer leaves a poor rating?

Route it to the team lead the same day, with the ticket and the customer's comment. The comment is the useful part. A rating handled on the day can still involve the customer, while a rating handled next week is only a statistic.

Should poor ratings go straight to the agent?

No. A poor rating that arrives with no context is demoralizing and does not help the agent improve. The lead can decide whether the rating reflects something the agent could have done differently or a problem elsewhere, such as a product defect or a documentation gap.

Related reading

• Freshdesk and CodeWords
• Connecting Zendesk to Slack
• CodeWords integrations and templates