OffboardingAccessSecurity

Deactivating an Employee in Slack Isn't Enough: Bots, Private Channels, and Apps That Stay Active

Slack deactivation blocks login but leaves bots running, private channels ownerless, and Slack Connect partners connected. Here's what actually survives and how to close the gaps.

7 min read

Deactivating an Employee in Slack Isn't Enough: Bots, Private Channels, and Apps That Stay Active

When someone leaves your startup, hitting "Deactivate" on their Slack account feels definitive. They disappear from the member list, lose channel access, and can't log back in. But deactivation is step one of a multi-step process — not the finish line. Slack bots they installed keep posting. Private channels they managed become ownerless. Slack Connect partners they invited remain connected. Here's what actually survives deactivation and what you need to do about it.

Why This Matters for Your Startup

At a 15–40 person startup, Slack isn't just a chat app. It's where automations run, customer support tickets surface, sales alerts fire, and sensitive conversations happen. If your Head of Operations built six Slack workflows before they left, three of them may still be running under their identity. If your customer success manager managed your Slack Connect channel with your biggest client, that relationship is now in limbo.

The problem is invisible. Nobody gets an alert that says "bot still active under departed employee." The workflow keeps firing, the bot keeps posting, and the first sign anything is wrong is often a confused customer or a misfired automation — weeks later.

What Slack Deactivation Actually Does (And Doesn't Do)

When you deactivate a member in Slack, here's what it does do:

  • Blocks their ability to sign in to your Slack workspace
  • Removes them from all channels (public and private)
  • Revokes their user-level API tokens — so any personal OAuth integrations they set up using their user identity stop working
  • Retains their messages and files (Slack keeps the history)

That sounds comprehensive. The catch is in the third bullet: user tokens are revoked, but bot tokens are not. Slack draws a hard line between a user identity and a bot identity. When someone installs a Slack app, that app often operates under its own bot token, which is independent of the installing user. Deactivating the installer has no effect on the bot's token or the app's continued operation.

Slack has explicitly moved toward bot tokens over user tokens for this reason — bot tokens are stable across user lifecycle changes. From the platform's perspective, this is a feature. From an offboarding security perspective, it's a gap.

The Bot Problem: Apps That Keep Running After Someone Leaves

Modern Slack apps — Zapier bots, sales alert automations, support ticket integrations, custom Slack workflows built with slash commands — run on bot tokens. When the person who installed them leaves and you deactivate their account, the app keeps running exactly as before.

The practical risks:

Automation apps (Zapier, Make, n8n): If the departed employee set up a Zapier Slack bot to post daily sales reports or trigger onboarding reminders, those workflows continue. The messages appear to come from the bot, with no indication that the human who built them is gone. If the automation is doing something wrong — posting outdated data, hitting a deprecated API — nobody's watching it.

Custom slash commands and webhooks: Incoming webhooks tied to a custom integration can post to channels indefinitely. Slack does not revoke incoming webhook URLs on user deactivation. If the departing employee created the webhook, its URL is still valid.

What to do: Go to your Slack workspace Settings → Apps → Manage Apps. Review every installed app. For each one, check who installed it and what it does. Apps that were functionally owned by the departing employee should be either reassigned (if possible through the app's own admin settings) or removed and reinstalled by the new owner.

Note: In November 2026, Slack is discontinuing support for "classic apps" — older-style integrations built before Slack's current app platform. If your workspace has any legacy bot users or custom integrations, this transition is a natural forcing function to audit and clean them up.

Private Channels Without an Admin

When a member is deactivated, Slack removes them from all channels — including private ones they managed. The issue: if they were the only Channel Manager for a private channel, that channel loses its manager.

Slack's permission model assigns the "Channel Manager" role to the creator of a channel. Channel Managers can archive channels, add members, and convert public-to-private. When the Channel Manager leaves, Workspace Admins retain override authority — they can step in to manage any channel. But that requires you to know the channel exists in the first place.

Private channels created by the departed employee won't show up in the default channel list for people who weren't members. If your Head of Product ran a private #product-roadmap-sensitive channel with three engineers and then departed, that channel goes dark. The remaining members can still use it, but nobody can add new members, rename it, or archive it cleanly — until a Workspace Admin intervenes.

What to do: After any offboarding, go to Settings → Channels in your Slack admin console. Filter by Private channels. Look for channels where the creator has been deactivated. For each one, add yourself or a current team lead as a Channel Manager, then decide whether to keep, archive, or merge the channel.

Slack Connect: External Partners Still Connected

Slack Connect allows two separate companies to communicate inside a shared channel. If your sales lead managed a Slack Connect channel with your three biggest customers, deactivating their account removes them from the channel — but the external organization and their members remain connected to your workspace.

This creates two problems. First, the external partner is now in a channel that has no active manager on your side. Second, their Slack bot integrations on their end still have access to that shared channel. They can still post, read history, and trigger any automations tied to it.

From a customer-experience perspective, nobody's notifying the customer that their contact left. From a data perspective, your customer now has access to a channel where your team might post internally expecting the context of "this is a customer channel." Confusing posts, misdirected messages, sensitive pipeline updates — the risks compound.

What to do: Before deactivating a member who manages Slack Connect channels, identify all shared channels they own. Reassign channel management to a current team member. Then notify the external contact that their point of contact has changed. Slack Connect channels won't disconnect automatically on deactivation — you have to manage this manually.

The 5-Step Slack Offboarding Protocol

Do these in order, before you hit deactivate on the account:

Step 1: Identify their app installations Go to Settings → Apps → Manage Apps. Filter by "Installed by" if your plan supports it (Business+/Enterprise plans). List every app the departing member installed. Note which use bot tokens (these will survive deactivation and keep running).

Step 2: Audit and reassign automations For each bot-token app they installed, decide: keep it running (assign a new owner in the app's own admin settings), remove it, or rebuild it under a service account. Apps installed under a general team login rather than a personal account are safer — they don't tie the app's operational status to one person.

Step 3: Handle private channels before deactivation Run a private channel audit from your Slack admin console. For channels where the departing employee is the sole manager, add a current team member as co-manager before deactivating.

Step 4: Reassign Slack Connect channels List all Slack Connect channels. For each one the person managed, assign a current team member as the primary contact and notify the external partner of the change.

Step 5: Deactivate and review apps one more time After deactivation, go back to Manage Apps. Confirm that any user-token-based apps (personal integrations, not bots) have stopped working. Watch for bot-token apps that are still active — those need manual removal or ownership transfer if you don't want them running.

Slack is one piece of the offboarding puzzle. If you're also managing Google Workspace, read 7 Google Workspace Offboarding Mistakes Startups Keep Making. For the broader multi-tool picture, see How to Offboard an Employee Across 12 SaaS Tools When You Have No IT Team.

FAQ

Does deactivating a Slack user remove all their access? No. Deactivation blocks login and removes the user from channels, but bot-token apps they installed continue running. Slack Connect channels they managed remain open. Incoming webhooks they created remain valid. Deactivation is necessary but not sufficient.

Will bots and automations stop working when I deactivate the employee who set them up? Only if those bots use user tokens (which is rare for modern Slack apps). Apps built on bot tokens are designed to survive user lifecycle changes — so they keep running after deactivation. You need to manually audit and remove or reassign them.

What happens to private channels if the only admin leaves? The channel remains accessible to existing members, but loses its Channel Manager. Workspace Admins can regain control from the admin console. The risk is that nobody knows to look for ownerless private channels unless there's a post-offboarding audit process.

Can a deactivated Slack user still appear in Slack Connect channels? Once deactivated, they're removed from the shared channel. But the external organization remains connected, and any automations on their end still have access to the channel. The relationship persists — only the person is removed.

The Right Tool for This

Slack offboarding isn't a one-click operation — it's a checklist of decisions across apps, channels, and external connections. The problem is that most startups don't have a system for tracking who set up which bots or who manages which Slack Connect partner. It surfaces only at offboarding, when you're doing it manually for the first time.

Optserv tracks the full employee lifecycle — including which tools each person owns, manages, or has installed across your stack. When someone leaves, you get a structured checklist that covers Slack app installations, private channel ownership, and Slack Connect relationships alongside every other SaaS tool they touched. Try Optserv at app.optserv.ai.

Sources

Run your entire team from one place.

Optserv handles hiring, onboarding, access management, and offboarding — built for startups that want to operate like grown-ups without the enterprise overhead.

Try Optserv free