Every permission GridKeeper asks for, and why.

What GridKeeper never asks for

No scope that reads message content, ever. No scope that lets GridKeeper post, edit, delete, or send anything. No scope that lets GridKeeper install, remove, or approve an app on your behalf. If a future feature would need one of these, that's a different, clearly-labeled product, not GridKeeper.

The two scopes that are broader than reading

Slack's permission model does not offer a read-only version of everything, so two of the scopes in the table above allow more than GridKeeper does with them. Being direct about that is worth more than a table that quietly implies otherwise. GridKeeper contains no write call to Slack anywhere, on any plan, which is a fact about how the product behaves rather than a promise made here.

conversations.connect:manage, requested on every plan. Slack bundles reading your Slack Connect invitations together with approving them, declining them, and disconnecting an outside organization. GridKeeper only lists them. We checked for a narrower route rather than assuming there was none: a token holding only team:read asked Slack for the list of connected organizations, and Slack refused, naming this scope as the one required. Dropping it would remove the Slack Connect checks altogether.

admin, requested on Pro and Business+ only. Slack's legacy workspace-admin scope, broad and not limited to reading. On those plans it is the only way to see three things: dormant accounts (last login), who installed an app and when, and paid seats nobody is using. Enterprise Grid does not need it, because the narrower admin.* scopes cover that ground, so a Grid install is never asked for it.