Disconnecting a Slack workspace from Zendesk is a two-sided change. To fully undo the integration, you disconnect the Slack workspace inside Zendesk and remove the Zendesk app from Slack. This guide walks through both, explains what happens to your existing tickets and triggers afterward, and covers what to think about before you decide to run support without a Slack–Zendesk bridge at all.
Common reasons teams reach this page:
- Migrating off Zendesk to another helpdesk.
- Switching Zendesk instances (sandbox → production, or consolidating domains).
- Cleaning up an old integration as part of a security or permissions review.
- The native app never quite fit how your team actually uses Slack, and you want a clean slate before choosing a different approach.
‍
Step 1: Disconnect the Slack workspace from inside Zendesk
This stops Zendesk from posting into Slack via its native Slack app — ticket-event notifications, side conversations initiated from a ticket, and any trigger-driven messages that fan out into Slack channels.
Zendesk’s Admin Center UI evolves over time; the current labels are documented in the Zendesk Help Center’s Slack for Zendesk Support listing. The high-level flow is stable:
- Sign in to Zendesk as an Admin and open the Admin Center.
- Go to Apps and integrations → Integrations → Integrations.
- Find the Slack section and open it.
- Locate the Slack workspace you want to remove, open its configuration, and choose the disconnect action.
‍
Step 2: Remove the Zendesk app on the Slack side
Disconnecting on the Zendesk side stops Zendesk from posting outbound, but the Zendesk app remains installed in your Slack workspace with whatever permissions it has. If you also want to revoke that access — for offboarding, a security review, or just a clean uninstall — do it from Slack too:
- Open Slack and go to your workspace’s Apps section.
- Find the Zendesk app in the installed apps list.
- Open its settings and choose to remove or uninstall the app from the workspace. A Workspace Owner or Admin may need to approve this if app management is restricted.
Doing only one side leaves a mess: disconnecting only in Zendesk leaves the app installed in Slack; removing only from Slack leaves stale trigger references in Zendesk that will start failing to deliver.
‍
What happens to your existing tickets and triggers
- Zendesk tickets are unaffected. Disconnecting the Slack app does not delete or modify any Zendesk tickets, macros, or views.
- Triggers keep firing, but the Slack action fails. Any Zendesk trigger that had a “notify Slack” action stops delivering. It’s worth going through your triggers and either removing the Slack action or disabling the trigger to avoid noise in Zendesk’s activity log.
- Side conversations from Slack lose their bridge. Existing ticket-linked side conversations stop syncing new replies once the workspace is disconnected; the historical thread stays in the ticket.
- Slack channels stay put. Channels that were receiving ticket events remain, just quiet. Consider archiving unused “#zendesk-alerts”-style channels so team members don’t assume they’re still live.
‍
Reconnecting later
If you disconnected temporarily — for a Zendesk subdomain change, a sandbox test, or a permissions cleanup — the native Slack app can be reinstalled from Zendesk’s Marketplace using the same install flow you used originally. You’ll need to reconfigure any trigger-based Slack notifications from scratch, since disconnecting removes the workspace configuration.
‍
Before you rebuild: what the native app couldn’t do
A lot of the teams who arrive at this page aren’t leaving Zendesk — they’re leaving the way the native Slack app connects Zendesk to Slack. Zendesk’s built-in app is a notification and light-collaboration layer: it fans ticket events into Slack channels and lets an agent create a ticket from a Slack message. That’s useful, but it’s not a support experience inside Slack.
If any of the following sound like the reason you’re disconnecting, it’s worth taking a fresh look at how a Slack–Zendesk bridge could work before you rebuild:
- Customers and internal users message us in Slack, but their messages don’t become tickets automatically. The native app converts a message on demand. It doesn’t automatically turn every new thread in a customer Slack Connect channel or internal support channel into a Zendesk ticket.
- Replies typed in Slack don’t make it back into Zendesk. The native app doesn’t bi-directionally sync a Slack thread with its Zendesk ticket, so anything an agent (or requester) types in Slack after the ticket is filed lives outside Zendesk.
- We can’t collect the information we need at intake. Zendesk fields marked “required to solve” can’t be enforced through the native app’s Slack-side create flow, so tickets land underspecified and get bounced back to the requester.
- The internal team needs a private space to triage a live customer thread. The native app has no notion of a private triage channel attached to a customer Slack conversation, so triage tends to happen in DMs and never makes it into Zendesk.
- CSAT collected in Slack never reaches the Zendesk ticket. Zendesk’s own CSAT surveys assume the conversation lives in Zendesk; when it lives in Slack, the responses don’t make it back to the ticket.
- Agents want to work Zendesk tickets that originated in email or the Help Center — from Slack. The native app can notify Slack when such a ticket is created, but agents still have to switch to Zendesk to actually reply.
These are exactly the gaps ClearFeed was built to close — bi-directional Slack ↔ Zendesk sync, automatic or emoji-triggered ticket creation from Slack channels, structured intake forms mapped to Zendesk fields, private triage channels, CSAT sync back to Zendesk tickets, and a reverse flow that pulls email/Help Center tickets into Slack for agents to work end-to-end. If the reason you’re disconnecting is one of the bullets above, the answer might not be “no Slack–Zendesk bridge” — it might be a different one.
‍
Think through the change before you flip it off
See how ClearFeed handles Slack + Zendesk or book a demo — a 20-minute walkthrough is usually enough to decide whether a different bridge would fit your team better than what you just disconnected.
