Invalid_team_for_non_distributed_app Slack
You fix the invalid_team_for_non_distributed_app slack error by turning on public app distribution. You can also fix it by installing the app in its home workspace. Teams often build a bot in a test workspace first. Then they try to install that same bot into a main workspace. Without public sharing turned on, the login flow blocks the outside workspace. Teams then grant broad admin roles or share workspace keys to bypass the block. That shortcut puts chat data and linked cloud systems at risk.
Non-Human Identity Management + Red Team Operations: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You fix the invalid_team_for_non_distributed_app slack error by turning on public app distribution. You can also fix it by installing the app in its home workspace. Teams often build a bot in a test workspace first. Then they try to install that same bot into a main workspace. Without public sharing turned on, the login flow blocks the outside workspace. Teams then grant broad admin roles or share workspace keys to bypass the block. That shortcut puts chat data and linked cloud systems at risk.
Why the invalid_team_for_non_distributed_app slack error happens
Every new chat app starts locked to one home workspace. Only members of that home workspace can authorize or install the app. This rule protects private tools while developers build and test them. When a user from another team clicks the install link, the check fails. The login server compares the user team ID against the app home team ID. If the two team IDs do not match, the platform stops the login.
To allow other workspaces, you must turn on public distribution in the dashboard. This setting does not publish your bot to the public app store. Instead, it tells the login system to accept installs from outside workspaces. Before you turn this on, the dashboard checks a few basic items. You must set up a valid redirect URL for the login callback. You must also remove any hard-coded keys from your app code. Once you complete those checks, any workspace you invite can install the app.
How workspace scopes and bot tokens work
When a workspace installs a distributed app, the login flow asks for scopes. Scopes define what the bot can read or write in that workspace. After an admin approves the request, the platform issues a workspace bot token. Your app stores this token and uses it to send messages or run tasks.
Each workspace gets its own unique token during the install process. A single distributed app might hold dozens of tokens across many teams. Developers often request broad scopes so they do not hit permission errors later. A bot might ask to read all channels, manage users, and run workflows. If the bot triggers backend jobs, those broad scopes become dangerous. Anyone in the chat workspace can talk to the bot and trigger backend actions.
Non-Human Identity Management + Red Team Operations: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What app distribution solves and what it leaves open
Public app distribution solves the multi-workspace install problem for your team. It lets you build an app once and share it across many workspaces. It also separates workspace tokens so one team cannot read another team's chat.
Still, workspace login and app scopes only decide where the bot can join. They do not control what the bot or its users do inside backend systems. Once a user runs a chat command, the backend service runs with full power. Native bot scopes cannot check the exact database query or server command in flight. They also cannot mask sensitive fields like emails, phone numbers, or card numbers. If a query returns national IDs into a chat channel, native scopes will not rewrite those fields. Teams need a deeper control point to inspect every command and rewrite matched fields in results.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
Does public distribution list my app in the public directory?
No, turning on public distribution only lets other workspaces use your install link. You must submit a separate review request to appear in the public directory.
Can I fix this error without turning on public distribution?
Yes, you can create a brand new app directly inside the target workspace. Then you copy your settings and keys over to that new home workspace.
Why does my enterprise grid workspace trigger this team error?
Enterprise grid setups contain many separate workspaces with different team IDs under one roof. An app built in one grid workspace still needs distribution turned on for others.