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

Freshdesk does a lot before a person sees a ticket. Dispatch rules classify and assign on arrival, observer rules react to changes, supervisor rules run on a schedule over tickets that have gone quiet, and SLA policies measure against a business calendar rather than the clock.

An integration that ignores all of that and computes its own conditions will disagree with Freshdesk about which tickets matter, which is a confusing way to lose the team's trust. The version worth building rides on the rules that already exist.

What we'll cover

• Three rule types that already run
• Business hours, which change every calculation
• Building it with CodeWords
• Messages that build on existing rules
• Escalating out of the helpdesk
• Agent workload, which nobody can see
• Groups and routing that stay in step
• Satisfaction ratings, which arrive after everyone has moved on
• Making it survive
• Limits worth knowing about
• What to set up first
• Frequently asked questions

Three rule types that already run

Worth understanding before building, because each is a hook you can use rather than reimplement.

Dispatch rules fire once, when a ticket arrives, and set priority, group, agent, and tags. Anything your integration needs to know about classification has usually already been decided here.

Observer rules fire on changes — a reply, a status change, a reassignment — and are the right place to trigger an outbound notification from.

Supervisor rules run on a schedule over tickets matching conditions, which is how Freshdesk handles "nothing has happened for too long". This is the mechanism for anything about staleness.

SLA policies define response and resolution targets, per priority and per group, measured against a business calendar.

The practical approach: let Freshdesk decide which tickets are interesting, using the rules the support team already maintains, and let the integration decide who hears about it and what the message says.

Business hours, which change every calculation

The detail that makes a locally computed alert disagree with Freshdesk.

SLA targets are measured in business hours, so a ticket raised at five on Friday with a four-hour target is not late on Saturday morning.

Calendars differ per group. A team covering one region and a team covering another have different clocks, and a single global calculation is wrong for at least one of them.

Holidays are configured and a calculation that ignores them will alert through a public holiday, which is the fastest way to teach people to mute a channel.

Some policies run around the clock and others do not, often within the same helpdesk, so there is no single answer to apply.

Read Freshdesk's own due-by times rather than computing your own. They are on the ticket, they already account for all of the above, and using them means the integration and the helpdesk always agree.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: 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; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Messages that build on existing rules

A supervisor rule adds a tag; your integration watches for it. The support team controls the condition in Freshdesk, where they can adjust it, and you control the message. This is the arrangement that stays maintainable.

Approaching the due-by time, using Freshdesk's own value, sent to the assigned agent before it passes rather than after.

A ticket dispatch could not classify, which lands in a default group and sits there because nobody owns the default group.

A high-priority ticket unassigned past a short threshold, since priority without an owner is the combination that goes wrong.

A ticket reopened after resolution, to the agent who resolved it, because a reopen usually means the fix did not work.

A customer response on a ticket waiting on them, so the agent picks it up promptly rather than on the next queue sweep.

Escalating out of the helpdesk

The reason a support team wants Slack at all.

Agents need people who do not use Freshdesk — engineers, account managers, finance — and adding them as agents is neither practical nor cheap.

Post the question with the relevant detail extracted, not a ticket link, since 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 on the ticket, so the conversation is on the record and the next agent to touch it sees the reasoning.

Route by topic to a channel with the right people, and time out to a named person if nobody responds.

Count what is escalated and about what. The recurring topics are a documentation gap, and the list is the specification for filling it.

Agent workload, which nobody can see

A reporting gap that Slack is well placed to fill.

Open tickets per agent is visible in Freshdesk and nobody looks at it during a busy day, which is exactly when it matters.

Report imbalance rather than counts. 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, since that is the urgent half of the workload.

Post at shift start, when somebody can act on it, rather than at the end of the day.

Send it to the team lead, not to the whole team. A public workload ranking changes behaviour in ways that make the numbers better and the support worse.

Groups and routing that stay in step

Dispatch rules reference groups and agents that change as people join and leave.

A rule pointing at a departed agent silently stops assigning, and tickets accumulate in a queue nobody is watching.

Report tickets in the default group, weekly, since that is where unclassified work collects.

Report groups with no active agents, which happens after a reorganisation and produces a queue with no owner.

Check the rules against your directory periodically, because nothing in Freshdesk tells you a rule has become a dead end.

Satisfaction ratings, which arrive after everyone has moved on

Freshdesk collects customer satisfaction responses, and they land in a report nobody opens.

Route a poor rating to the agent's lead, quietly, on the day it arrives. A week later it is a statistic; on the day it is a conversation that can still involve the customer.

Include the ticket and what the customer wrote, since the comment is the useful part and the score on its own says nothing about why.

Do not route it to the agent automatically. A poor rating landing in somebody's messages with no context is demoralising, and the lead can decide whether and how to raise it.

Watch for patterns rather than individual scores. One poor rating is noise; three on the same topic is a product or documentation problem.

Celebrate the good ones in the channel. Support teams hear about failures constantly and successes almost never, and the imbalance is easy to correct.

Report response rate too. A satisfaction score calculated from four responses out of two hundred tickets is not a measurement of anything.

Making it survive

Read Freshdesk's due-by values rather than computing deadlines yourself.

Make it 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 one is, and alerting on it is noise.

Map agents to Slack users from your directory, reporting failures rather than dropping messages.

Report the outcome. Alerts sent, escalations raised, and notes written back.

Limits worth knowing about

Rate limits apply per account and depend on your plan, so scanning many tickets needs pacing.

Some automation features are plan-dependent, so the rule types available differ between tiers.

Ticket descriptions contain whatever the customer wrote, so channel membership matters and Slack is a separate copy of it.

Custom fields vary per helpdesk, so anything reading one must handle its absence.

Webhooks from automation rules are at-least-once, which is why idempotency matters.

What to set up first

An approaching due-by alert using Freshdesk's own value, sent to the assigned agent before the deadline passes. It agrees with the helpdesk by construction, it needs no deadline arithmetic, and it catches the ticket while there is still time to do something about it.

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

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 guarantees the integration and the helpdesk eventually disagree, and the helpdesk is right.

How should conditions be defined?

In Freshdesk, using supervisor or observer rules, with the integration reacting to the tag or the change they produce. The support team can then adjust the condition themselves, which keeps it maintainable.

Why do alerts fire on a public holiday?

Because the calculation ignored the business calendar. Holidays are configured in Freshdesk and reflected in due-by times, which is another reason to read those rather than compute from ticket age.

How do agents get help from people outside Freshdesk?

Post the question with the detail extracted into a channel with the right people, and write the reply back onto the ticket as a private note. Adding engineers as agents is neither practical nor cheap, which is why this route matters.

What about the default group?

Report it weekly. Tickets that dispatch rules could not classify land there and sit, because a group that belongs to nobody in particular is a queue nobody sweeps.

Should workload reports be public?

Send them to the team lead. A public ranking of open tickets per agent changes behaviour towards closing tickets rather than resolving them, which improves the number and not the support.

Why did a dispatch rule stop assigning?

It probably references an agent or group that no longer exists. Nothing tells you, and tickets quietly accumulate unassigned. Checking rules against your directory periodically is the only thing that catches it.

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, and a rating handled on the day can still involve the customer, where one handled next week is only a statistic.

Should poor ratings go straight to the agent?

No. A poor rating arriving with no context is demoralising and does not help. The lead can decide whether it reflects something the agent could have done differently or a problem elsewhere, which is often the case.

Related reading

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