How to connect Zendesk to Slack for tickets that are about to breach

To connect Zendesk to Slack usefully, alert assignees before a ticket breaches its service level agreement (SLA), and escalate questions to people outside support. Posting every new ticket into a channel adds noise, because agents already have a queue. Warnings and escalations change outcomes.

Key takeaways

• Do not post every new ticket to Slack, because Zendesk's queue already does that job better.
• Alert the assignee when a set share of the SLA time has elapsed, not after the breach.
• Calculate deadlines from Zendesk's own SLA policy, including business hours.
• Post the question and customer context to escalations, and write the answer back to the ticket as an internal note.
• Keep ticket bodies out of broad channels, because Slack keeps a separate copy that Zendesk privacy deletions do not reach.

What we'll cover

• Why new tickets in a channel is wrong
• Predicting a breach rather than reporting it
• Building it with CodeWords
• Escalating to somebody outside support
• Keeping the conversation in one place
• Messages worth sending to the wider company
• Customer data in a channel
• Handover between shifts and regions
• Making it survive
• Limits worth knowing about
• What to set up first
• Frequently asked questions

Why new tickets in a channel is wrong

Posting new tickets to a channel is wrong because it duplicates the queue in a worse interface. Agents decide what to work on from Zendesk views, which are built for that job.

• Volume makes the channel unreadable. A team receiving hundreds of tickets a day produces a feed nobody can scan, and the important ticket looks like the routine one.
• Ownership becomes ambiguous. A ticket in a channel looks like anybody's, which is what assignment rules exist to prevent.
• Nobody can act on it there. The message repeats information without adding a way to use it.

The exception is a low-volume, high-stakes queue, such as security reports or escalations from named accounts, where a handful of tickets a week each deserve attention.

Predicting a breach rather than reporting it

Predict a breach by alerting at a share of the SLA time remaining, not at the breach. A breach notification reports a failure that has already happened. An alert at 75 per cent of the time elapsed, with no first reply, leaves time to act.

• Account for business hours. An SLA measured in business hours has a real deadline that a simple ticket-age calculation gets wrong. An alert on Saturday for a deadline on Monday teaches people to ignore alerts.
• Send the first alert to the assignee. Send the team lead a second alert only at a later threshold: the first message is a nudge and the second is a problem.
• Name the obligation at risk. First reply, next reply and resolution are different obligations, and the message should say which one.
• Report the pattern weekly. Which queues run close to breach, and at what times of day, is a staffing question that individual alerts never answer.

Building it with CodeWords

CodeWords connects to 3,000+ integrations (CodeWords integrations directory, 2026), and you make each connection once and reuse it.

1. Open CodeWords and start a new automation.
2. Describe to Cody, the automation builder, what should happen: which views or conditions, what threshold, and who should be told.
3. Authorize the Zendesk connection with an API token for a dedicated user, and connect your Slack workspace.
4. Describe the exceptions: a ticket already solved, an assignee who is away, a ticket paused pending the customer.
5. Test against a Zendesk 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 covers light use. Pro costs $39 per month and Business costs $100 per month (CodeWords pricing page, 2026). Details are on the pricing page.

Escalating to somebody outside support

Escalate by posting the question, with customer context, into a channel where the right people are. Agents often need an answer from engineering, product or account management, and those people do not use Zendesk. This is the main reason support teams want a Slack integration.

• Post the question, not the ticket link. A link asks the reader to study a thread. A question with context can be answered.
• Include who is affected and how urgent. An engineer deciding whether to switch tasks needs the account and the deadline, and both are in Zendesk.
• Route to a specific channel. An escalation in a channel of forty people reaches nobody.
• Bring the answer back. The Slack reply should land on the ticket as an internal note, or the knowledge stays in a chat thread nobody searches.
• Count escalations by topic. A recurring topic points to a documentation gap, and only counting makes it visible.

Keeping the conversation in one place

Keep the conversation in one place by writing Slack replies back to the ticket as internal notes. The common failure of support-to-chat integrations is a discussion in Slack that the ticket never records.

• Link the Slack thread on the ticket, so a later reader can find the full discussion.
• Write customer-facing replies in Zendesk only. A reply to a customer belongs in the tool that records it, with the ticket history and the agent's judgement about tone in view.
• Treat the ticket as the record. When the two disagree, the ticket wins, and the integration should reinforce that.
• Post to the Slack thread when the ticket is solved, which closes the loop for whoever helped.

Messages worth sending to the wider company

Send the wider company only messages that a specific group can act on. Five qualify:

Message	Recipient	Timing
Spike in tickets about one thing	Engineering and product	Immediately, as an early incident signal
Named account raising a serious issue	That account's owner	Immediately
Ticket mentioning cancellation	Whoever owns the relationship	Promptly
Customer requests, counted	Product	Weekly
Everything else	Nobody	Never

A general support feed guarantees that the messages above get lost.

Customer data in a channel

Ticket content can contain anything a customer chose to write, including account details and occasionally credentials. Treat a channel as a separate copy of that data.

• Check channel membership before pointing anything at a channel, and prefer private channels for ticket bodies.
• Send a summary and a link where the channel is broad. The person who needs detail opens the ticket, where access is controlled.
• Redact obvious sensitive patterns before posting where you can.
• Retention differs. Zendesk has a deletion process for privacy requests. A Slack channel is a separate copy that the deletion does not reach.

Handover between shifts and regions

Handover summaries stop the incoming shift from starting cold. Support teams that span timezones lose work at the boundary, and a channel closes that gap well.

• Summarise what is open, including what is waiting on whom.
• Name tickets close to a deadline, since the incoming shift should look at those first.
• Carry the context on mid-investigation tickets. A ticket where somebody was halfway through a theory is the one most likely to restart from scratch.
• Include escalations that have not come back. Items waiting on another team fall between shifts.
• Post to the channel both shifts share, in a consistent shape, so people read it.
• Write the same summary onto the tickets that matter, because the channel post scrolls away and the ticket does not.

None of this is technically hard. It is the work that never gets done consistently by hand, which is why it is worth automating.

Making it survive

Make the automation survive by keying alerts on the ticket and threshold, respecting ticket status and handling absent assignees.

• Make it idempotent, keyed on the ticket and the threshold crossed, so a ticket does not alert repeatedly for the same reason.
• Respect ticket status. A ticket pending the customer is not breaching the way an open one is.
• Map agents to Slack users from your directory, and report failures instead of dropping messages.
• Escalate when an assignee is away, so an alert to somebody on holiday does not disappear.
• Report the outcome: alerts sent, escalations raised and notes written back to tickets.

Limits worth knowing about

Five limits affect a Zendesk to Slack automation.

• Rate limits apply and depend on your Zendesk plan. A job scanning many tickets needs pacing.
• SLA policies are configured in Zendesk, with business hours and per-target definitions. An integration that calculates its own deadlines will disagree with Zendesk.
• Ticket bodies can be long. Truncate messages and link to the ticket.
• Slack retention is a workspace setting, unrelated to Zendesk data retention.
• Triggers and scheduled scans differ. Zendesk triggers fire on events. A ticket approaching its deadline generates no event, so a scheduled scan has to look for it.

What to set up first

Set up SLA risk alerts first: tickets at a set share of their time remaining, respecting business hours, sent to the assignee. The alert catches the ticket about to breach while there is still time, which a breach notification cannot do.

Two habits make the difference. Calculate against Zendesk's own SLA policy instead of ticket age, because business hours and per-target definitions make the two numbers very different. And name which obligation is at risk (first reply, next reply or resolution), because the action differs for each.

Frequently asked questions

Should new tickets post to a Slack channel?

Generally no. Agents work from the Zendesk queue, which is built for deciding what to do next, and volume makes a channel unreadable. The exception is a low-volume, high-stakes queue where every ticket deserves attention, such as security reports or escalations from named accounts.

When should an SLA alert fire?

Fire the alert before the breach, at a set share of the time remaining, calculated against the Zendesk SLA policy including business hours. A breach notification reports a failure that has already happened, while an earlier alert gives the assignee a chance to prevent it.

How should agents get help from engineering?

Post the question with customer context into a channel where the right engineers are, then write the answer back onto the ticket as an internal note. A bare ticket link asks engineers to read a whole thread, which is why those escalations sit unanswered.

Is it safe to put ticket content in a channel?

Only with care. Ticket bodies contain whatever the customer wrote, sometimes including sensitive details, and Slack holds a separate copy that Zendesk privacy deletions do not reach. Send summaries and links instead of full bodies, and use private channels.

Should customer replies be sent from Slack?

No. Write customer-facing replies in Zendesk, which records them with the ticket history in view. Internal discussion in Slack is fine, provided the automation writes the useful parts back to the ticket as internal notes.

What should the wider company receive?

Very little: a spike in tickets about one issue, a serious problem from a named account, a cancellation signal, and a weekly count of what customers ask for. A general support feed buries those messages and teaches people to mute the channel.

Why use a scheduled scan rather than triggers?

Use a scheduled scan because the condition you care about is nothing happening. Zendesk triggers fire on events. A ticket approaching its deadline without a reply creates no event, so something has to look for it on a schedule.

Can this help with handover between regions?

Yes. A consistent summary at handover lists what is open, what is close to a deadline, what is mid-investigation and what escalated without a reply. The incoming shift then continues the outgoing shift's work instead of restarting theories that were nearly finished.

What gets lost between shifts?

Tickets waiting on another team, and tickets where somebody was halfway through an investigation. Both look ordinary in a queue. A handover summary that names them stops the next shift from missing the waiting tickets or repeating the investigation.

Related reading

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