Intercom Slack integration: what it does and what it can't

Intercom has three Slack products. Pick by situation:

• Native integration (Settings > Channels > Slack): customer conversations from Slack channels, including private Slack Connect channels. Available on all Intercom helpdesk plans, per the setup article.
• Channeled (paid add-on): intake from external contacts, either every message or only on an emoji, mention or keyword.
• Legacy Intercom app for Slack: notifications only, no inbound support.

The setup problems below come from Intercom’s help pages and Slack’s app approval page as I read them on 2026-11-10. Intercom’s articles show “Updated yesterday” or “Updated over 3 weeks ago” rather than a calendar date, so re-read them before you build a process around a limit.

What the native integration does

Each Slack channel has a purpose, and you choose it before you connect the channel. Notification only channels are for alerts and updates and create no Intercom conversations. Conversational channels create synced conversations. A channel can’t be both.

In a Conversational channel, every customer message starts a conversation by default. You can narrow that to three triggers: a mention of a specific user or bot, a specific emoji reaction, or a keyword. Keywords match case-insensitively. Custom emoji don’t work as triggers, only Unicode emoji. The article contradicts itself on reactions: the trigger list includes an emoji reaction, but the limitations section says reactions in the Inbox “don’t trigger actions or store data.” I read the trigger as the setting that starts a conversation and the limitation as how reactions display afterwards, but test the emoji trigger on one channel before relying on it.

The trigger changes your queue. Take a shared channel that gets 400 messages a week, 120 of them real requests. On the default, Intercom opens 400 conversations and someone closes the 280 that were thanks and banter. On an emoji trigger, only the 120 that a customer marked become conversations. The cost is that customers have to learn the emoji, so watch a week of traffic to see whether they use it before you switch.

The article says Inbox replies post back as part of the same Slack thread, with the teammate’s name and avatar. A teammate who connects their own Slack account in Intercom replies as themselves, which requires the “Can manage workspace data” permission. Without that connection, a non-image attachment from a teammate is posted by the Fin bot.

Assignment and response times. The setup article says nothing about assigning Slack conversations or SLAs. It says reply-time expectations are configured in Simple Automations or Workflows, and workflow-based automation is on the Advanced and Expert plans, not Essential. So a Slack conversation lands in the Inbox like any other and you build routing and timers yourself. Plan for the clock: the article doesn’t say whether a timer you build counts from the Slack message time or from when the conversation was created, so check that in your first test. If it counts from creation, a customer who has already waited in the channel will not see it as a fresh start. The related guide on Slack Connect first-response targets covers what to promise.

Install, and the admin steps that block it

Go to Settings > Channels > Slack, choose Add channels, tick the channels, and set each one to Conversational or Notification only. For a private channel, open the channel’s member list, go to Integrations, choose Add an app and select Fin, or type @fin in the channel. The migration guide names the same bot “@Intercom”, so check the name your workspace shows before you type a mention.

Four things block an install or stop a channel from working, and each needs a Slack or Intercom admin:

• App approval. When a Workspace Owner turns on app approval, members can install only apps an owner has approved. They can request others, but a restricted app can’t be installed or requested at all. Get approval before setup day, not on it.
• Enterprise Grid. The app can’t be installed in the primary workspace of an Enterprise Grid account. Install it in a secondary workspace.
• Free Slack plan. Slack’s free plan allows only 10 apps. If you’re at the limit, remove one before you install.
• Multi-workspace mode. If more than one Intercom workspace connects to the same Slack workspace, each one turns on “Let this workspace handle Slack conversations alongside other Intercom workspaces.” Each channel then has to be claimed. Only workspace admins can click Claim channel, and the first claim wins. The article says adding Fin to a channel alone isn’t enough. DMs are disabled in this mode.

If a Conversational channel stays silent, check four things in order: the channel is set to Conversational, the app is a member of the channel, the trigger matches the message, and bot replies. Bot replies don’t sync to the Inbox by default. If Fin answers in a thread and you don’t see it, ask Intercom Support to enable syncing for bot replies.

What it cannot do

• Tickets from Slack. The article says “Intercom does not support creating tickets directly from Slack.” Create the ticket from the Inbox after a Slack message has made a conversation. Status changes then post back to the Slack thread.
• Reactions from the Inbox. “You can’t react to Slack messages from the Intercom Inbox.” Reply in the thread instead.
• Custom emoji triggers. Only standard Unicode emoji start a conversation.
• Replies as the customer. Replies go out as the teammate, as the teammate’s own connected account, or as the Fin bot. The article doesn’t describe a mode that posts a reply into the customer’s own workspace as a person.
• Formatting. Broadcasts are text only and take no attachments. Multi-level lists don’t render in the Inbox. The article lists AI Inbox translation and attribute collectors as unsupported.
• Public channels. Sensitive custom data attributes shared in a public channel are visible to every channel member, and reply-time automations can expose the customer’s email address. Review those attributes before you connect a public channel.

Slack Connect: what’s documented and what to test

The main setup article says new customer messages in a private Slack Connect channel create Intercom conversations. It describes Slack Connect as “connecting channels across different Slack organizations.” It doesn’t say which side has to install the app, so don’t assume the customer’s workspace is covered.

Run this check in one channel before you commit. A failed test looks like one of these: no conversation appears (the app isn’t in the channel, or the customer’s side blocks it), the reply shows in the Inbox but not in the customer’s Slack, or the reply appears under a bot name. If it fails, stop and ask Intercom Support which side must install, and keep that channel on your current process until they answer in writing.

• Inbound. Post a top-level message from an outside account. Expect one conversation in the Inbox.
• Outbound. Reply from the Inbox. Check that the reply lands in the Slack thread with the teammate’s name and avatar.
• Thread follow-up. Post a second message in the same thread from the outside account. Check whether it joins the open conversation or opens another one.
• Identity. Repeat the reply with a teammate who has connected their own Slack account, and compare the name shown.

Use an account that really belongs to the customer’s organization. The Channeled article says conversations must come from external contacts, not teammates. The native article doesn’t say that, so a teammate’s second account may not behave like a real customer.

The legacy app and Channeled

The legacy Intercom app for Slack is deprecated. Its help article says it “does not support Slack as an inbound support channel,” and it is available on the Advanced and Expert plans. It sends one-way notifications, and the article gives no sunset date, so plan the move now rather than wait for one.

Channeled is a different product. The article calls it a paid add-on across all Intercom plans, subscribed to separately from the native integration. You install it from Settings > Integrations > App store > Channeled, then run /invite-channeled in each Slack channel. Its automated mode creates a conversation for every message, and its manual mode creates one on an emoji, an @mention or a keyword. Messages from Slack bots or workflows create no conversations in either mode. The article says this is “by design” and recommends the Intercom REST API for creating those conversations.

The Channeled article doesn’t say whether it can run alongside the native integration. If you test both in one channel, check three things: one customer message creates exactly one conversation, a reply appears once in the Slack thread, and the same message doesn’t create a conversation in one product and a notification in the other. If any of those fails, give each channel one product.

Migrating: what to rebuild

The migration guide’s cutover runs in this order. Connect the new integration with Connect workspace in Settings > Channels > Slack and authorize Slack. Uninstall the legacy app once the new one works. Then re-authorize in the same settings page. Uninstalling the legacy app marks the new authorization as stale, and the guide allows up to 30 minutes for the integration to reconnect before new conversations flow. My recommendation is to schedule the switch in a quiet window of at least an hour.

Rebuild these, in this order:

• Channel inventory. Set Conversational or Notification only on every shared channel. Don’t carry an old setting over without checking it.
• Triggers. Set them per channel. A channel that mixes requests with thanks gets a keyword or emoji trigger.
• Private channels. The guide says to add @Intercom and set the channel purpose to “Post Slack notifications only.”
• Workflows. Notify Slack steps move to the new integration, but each step only shows channels connected in it. Check each step’s channel list.
• Reply identity. Teammates who should reply under their own name connect their Slack account. Keep that list.
• Legacy threads. The new bot always starts a new thread for a notification and can’t reply inside legacy threads. Name who closes open legacy threads before cutover.
• Past conversations. The guide doesn’t say whether they move. If you can’t get written confirmation from Intercom before cutover, export first and treat anything you can’t export as lost from the new setup. The legacy app was notification-only, so the history that matters is in the Inbox, which the export routes below cover.

Exporting conversation history

Six of Intercom’s export routes matter for an archive, and each has its own limit:

• One conversation. Click the three dots at the top right and export as text or PDF. Internal notes are excluded from transcripts.
• Bulk from the Inbox. 200 to 300 conversations per operation, as PDF or text.
• Saved View CSV. Needs the “Can export conversation data” permission and an Inbox seat. Up to 25,000 cells download immediately and larger exports arrive by email. Views above 100,000 conversations are refused, and system views such as Inbox can’t be exported. Exports are also refused while two are already running for the workspace.
• Dataset CSV. Up to 10,000 rows in the browser, data generally available for up to two years, and no conversation or message content.
• Export API. A maximum of 90 days per request, with no volume restriction.
• Historical S3 export. JSON covering up to two years, with no transcript.

Worked example: 12,000 conversations across 730 days. A bulk export at 200 to 300 per operation takes 40 to 60 operations (12,000 ÷ 300 and 12,000 ÷ 200), which is too many. The Dataset CSV stops at 10,000 rows and has no message text. The Export API takes 90-day windows, so 730 days is nine requests: eight full windows covering 720 days, plus one for the last 10 days. The page sets no volume limit on that. It doesn’t say how many calls each window needs or which fields the responses carry, so read the API reference before you design the archive.