Slack app management for a small team: who approves each app, what to check before you allow it, and a quarterly review in Slack

At a ten or forty person company, the person who created the Slack workspace is usually still its Workspace Owner, and nobody else looks at the apps. That is a problem because Slack lets members install apps without approval from a Workspace Owner by default. After a couple of years that can mean apps with scopes nobody read, some installed by people who have left, and no list of who owns what. Good Slack app management for a small team needs one owner, one request check, one register and a review four times a year. This guide gives you all four, plus the order to do them in.

The short version

1. Make an inventory of what is installed today, with one owner name per app.
2. Turn on app approval and name one or two app managers besides yourself.
3. Send requests to a private channel and answer each one against a five-question check.
4. Keep an app register in a spreadsheet: app, owner, why, scopes reviewed, end date.
5. Once a quarter, compare the register with the installed list and remove what has no owner, no reason or an owner who has left.

The rest of this article explains why each step exists and how to run it without an IT team.

Why apps pile up in a small workspace

Three defaults in Slack work against a small team that never decided anything about apps.

First, installs are open. Until someone switches on approval, any member can add an app and grant it what it asks for. The person installing is usually solving a real problem that afternoon: a poll, a stand-up bot, a calendar sync, a CRM notifier. Nobody writes down why.

Second, switching approval on later does not clean up the past. On the same help page, Slack notes that if you restrict an app that is already installed, members can continue using it. Approval governs new requests. It says nothing about the twelve apps that came in before you cared.

So turning on app approval does not touch the apps already installed, so the first job is an inventory, not a switch. If you flip the setting and stop, you have a gate in front of an empty field while the old apps keep their access.

Third, people leave and their apps do not leave with them in a clean way. Slack's page on deactivated members' apps and integrations explains that some apps a departed member installed deactivate and their API tokens are revoked, while bot users, slash commands and incoming webhooks stay active, along with a list of Slack-built apps that Slack keeps running regardless of who installed them. So when someone leaves, their bots, slash commands and incoming webhooks can keep running, so offboarding needs an app step, not just a deactivation. A webhook that posts sales numbers into a channel will happily keep posting after the person who set it up is gone, and nobody will know where to change it.

Apps hold tokens, and a token can leak at the vendor's end as well as yours. In August 2025, Google's threat intelligence team reported that attackers had stolen OAuth tokens from the Salesloft Drift platform and used them to pull data from customers' Salesforce instances. Its update said the compromise reached other integrations too, and its advice to customers was to review every third-party integration connected to the platform and revoke and rotate the credentials. Slack was not named in that report. For a small team the practical point is narrower. When a vendor tells you to revoke tokens, you need to know within minutes whether you use that vendor and who connected it. Without a register, you find out by asking in #general.

An old Hacker News comment makes the same point from the user's side: once an app is approved and a member subscribes to it, the public channels that member is in can be relayed to a third party. That is a commenter's description, not a Slack statement, but it is a fair summary of why the scope list matters.

Who approves: a rule for a 5 to 100 person firm

Large companies split this between IT, security and procurement. You have none of those, so keep the rule short.

• One accountable owner. Usually the founder or the operations lead who is already the Workspace Owner. This person decides on anything that reads messages, posts as people or touches customer data.
• One or two app managers. Slack lets Workspace Owners add selected members or user groups as app managers who can review requests. Pick people who are around every day, not the busiest person in the company.
• Every app has a business owner. Not the approver: the person who asked for it and will notice if it breaks. If they leave, the app gets a new owner or goes.

How to switch it on: in your workspace's admin settings, open App Management Settings, edit the approved apps setting and choose to allow only pre-approved apps. The exact steps are on Slack's app approval page. Do the inventory in the next section first, so you approve the apps people already rely on before anyone gets blocked.

Step 1: the inventory

Open Tools and settings, then Manage apps, and look at the Installed apps list, as described in Slack's guide to removing apps. Do not remove anything yet. For each app, write one row in a spreadsheet. Here is the register to copy:

The "Reads messages or files?" column is where you look at scopes. On a request, Slack shows the app's name, the requester, the list of permissions it would get and any comments. For apps already installed, open the app's page in Manage apps and read what it can access. You are not auditing code. You are answering one question per app: could this read conversations or files we would not want a vendor to hold?

On a small workspace this is an afternoon's work. If the list is long, split it by department and ask each lead to fill in the owner column.

Step 2: the request check

With approval on, requests go to all Workspace Owners and app managers, either as Slack messages or routed to a channel, depending on your settings. Route them to a private channel such as #app-requests so the decision and its reasons sit in one thread.

Slack publishes a set of security recommendations for approving apps. Most are written for a company with a security team. These five are the ones a small team can answer in two minutes, adapted from that list:

1. Is there a business reason, and who owns it? If the requester cannot name the job and the owner, the answer is not yet.
2. Do we already have an app for this? Two poll apps and three stand-up bots is how sprawl starts.
3. What does it read? Read the scope list on the request. Optional scopes can be left out when you approve.
4. What does it cost, and who maintains it? A free trial can turn into an invoice. A custom bot written by a contractor becomes nobody's job.
5. How long do we need it? Put an end date or a review date in the register.

Approve or restrict from the request itself. After you act, Slack updates the original request message for all app managers, so the channel shows the decision.

Slack's help pages describe how requests arrive and how to answer them, and neither the approval page nor the requests page mentions a reminder, a timeout or an expiry for a request nobody answers. Slack does not chase a pending app request for you, so the request channel needs a named person who answers and a reply-by day. This is a recommendation, not a Slack feature: agree that requests get an answer within two working days, and that the app manager on duty owns that clock. Otherwise the requester waits, gives up, and finds a workaround outside Slack, which is worse than the app.

Slack also lets Workspace Owners set up automations that approve requests based on conditions. For a small team, use that only for apps you have already reviewed once, such as re-installs of an approved tool. Automatic approval of anything new defeats the point of the check.

Step 3: offboarding has an app step

When someone leaves, add three lines to your offboarding checklist:

• Filter the register for apps they own. Give each one a new owner or mark it for removal.
• Check the installed apps for anything they set up that is not in the register, especially webhooks and slash commands, which keep running.
• If a bot integration is reinstalled under a new owner, Slack notes that its token is regenerated, so anything that used the old token needs updating. Tell whoever maintains the script.

Removing an app is done from the app's Configuration tab. With approval on, only Workspace Owners and app managers can remove apps, and you can also revoke a single person's authorisation instead of removing the app for everyone.

Step 4: the quarterly review, run from a Slack thread

Slack's own admin guide, Five steps to managing apps securely and at scale, walks through requesting, approving, installing and authenticating, and stops there. A current third-party guide on managing Slack app installations and permissions recommends regular permission audits without saying how often or who does them. Here is a version with a schedule and an owner.

Every quarter, the accountable owner spends 30 minutes on this checklist:

• Compare the installed apps list with the register. Anything installed but not in the register gets an owner or goes.
• Find rows whose business owner has left or changed role.
• Find rows past their end date.
• Re-read the "Reads messages or files?" column for anything added since last time.
• Check whether any vendor you use has announced a token or credential incident, and if so, revoke and reconnect that app.
• Remove what failed, and write the date of the review at the top of the sheet.

What the agent can do here, and what it cannot

If you use the Kipwise agent, the reminder and the first pass can run from a thread. You ask it once, for example: "On the first Monday of each quarter, read the App register sheet in Drive and list apps with no owner, owners marked as left, and rows past their end date." The agent runs requests on a schedule and posts the result in the channel, with the same tools and permissions as a live request from you. It reads the sheet with your own Google Drive access, which is how it acts with each person's own permissions. If it has not read a source, it says so instead of guessing.

Be clear about the limits. The agent does not read Slack's admin pages, does not see your installed apps list, and does not approve, restrict or remove Slack apps. The register is only as good as the inventory you made in Step 1, and removal stays a person's job in Manage apps. What the agent takes off your plate is remembering to look and doing the cross-check against the sheet.

How to judge an AI agent's app request

An AI agent usually asks for more access than a poll app does. Run the same five questions, then three more:

• Whose access does it use? An agent that acts with one shared bot token can reach whatever that token reaches. One that uses each person's own connected accounts can only reach what that person can open.
• What needs a person's approval? Look for a confirmation step before it changes a record, sends a message or posts in a channel.
• Can you see what it costs and who used it? You will be asked.

For the Kipwise agent specifically: it uses each person's own connected account for tools such as Drive, Gmail, HubSpot and QuickBooks, shows an Approve or Deny card before a live request changes something or posts a message, and team admins can ask it for a usage report by person or by day. Some organisations only let an administrator approve a new app, so the request will come to you like any other. Our AI agent security checklist for a small team goes deeper on what to test before an agent touches email, payments or the CRM.

When this goes wrong

• Someone needs an app today and you are away. That is why there are two app managers. If both are out, the reply-by rule still applies: answer "not yet, back Monday" in the thread so the requester knows.
• You remove an app and something breaks. Usually a webhook or slash command a team relied on. Ask in the app's channel before removing anything with an unknown owner, and give it a week.
• The register goes stale. It will, if the quarterly review skips a quarter. Put the review on a schedule rather than in someone's memory.
• You are on Enterprise Grid. Org-level policies, CSV export of installed apps and audit logs exist there and change the process. This guide is for a single workspace.

How you know it is working

After the first full quarter, you should be able to answer four questions in under a minute: how many apps are installed, who owns each, which ones can read messages or files, and which were added or removed since last quarter. Another sign is that app requests arrive in one channel with a reason attached, instead of in DMs to whoever seems senior. If a vendor announces a token incident, you can check the register and answer "we use it, Priya connected it, it is revoked" the same day.

What to do next

Do the inventory this week, before you switch on approval: open Manage apps, copy the installed list into the register above and put an owner name on every row. Then turn on approval, create #app-requests and add one app manager. If you want the quarterly check to run itself, try the Kipwise agent: it is $10 per user per month with a minimum of three users, and scheduling the review is one request in a thread. When you need ideas for what is worth adding back, our list of Slack apps for productivity and the guide to organizing Slack channels are good next reads.