Slack integration

2. Connection and scope

Seedling verifies the provider account before storing the connection. A personal connection remains actor-owned; a workspace connection is administered for the selected Seedling workspace. Credentials are never inferred from an email address or silently promoted between scopes.

Workspace bot token

A Slack administrator creates an app from Seedling's manifest, installs it to the intended workspace, and supplies the xoxb- Bot User OAuth Token.

Personal user token

An actor-owned xoxp- or xoxc- token may be used for a personal connection. Its raw content remains visible only to that Seedling member.

3. Slack data Seedling accesses

Seedling uses synchronized information for source-backed search, operating context, verification, and customer-approved workflows. Availability depends on the connected account, selected resources, provider plan, and native permissions.

Channels and conversations

Public and private channels, direct or multi-person conversations available to the token, channel metadata, topics, membership context, and stable IDs.

Messages and threads

Authorized messages, replies, timestamps, authorship, mentions, links, reactions and available message metadata.

Users and files

Visible user profiles and email addresses plus authorized Slack-hosted or remote file metadata and content needed for source-backed evidence.

4. Read-only permission contract

The published workspace-app manifest requests only read scopes. The runtime requires the core channel, history, file, and user scopes and reports the grant returned by Slack.

• channels:read, channels:history, groups:read, and groups:history — public and private channel metadata and history available to the app.
• im:read, im:history, mpim:read, and mpim:history — direct and group-direct conversations available to the token.
• users:read, users:read.email, and users.profile:read — workspace user identity and profiles.
• files:read and remote_files:read — authorized Slack file metadata and content.
• app_mentions:read, calls:read, canvases:read, links:read, metadata.message:read, and team:read — supporting workspace and message context.
• Seedling does not request chat:write, files:write, channels:manage, reactions:write, or other Slack write scopes.

5. Security and access

• Provider credentials and other connection secrets are encrypted in the workspace tenant data plane, never returned to the browser, and excluded from logs and queue payloads.
• Every source, synchronization, secret lookup, audience contribution, disconnect, and purge remains bound to the exact connection that created it.
• The provider does not expose enough object-level audience evidence for Seedling to reproduce every native permission safely. Workspace content therefore follows the connection's restricted-by-default policy; administrators and stewards receive no raw-content bypass.
• Personal-connection raw content remains visible only to the connecting member in human-facing Seedling surfaces.
• Private channels, direct messages, and files remain limited by what the supplied token and installed app can access. Seedling does not treat Slack administrator status as a content bypass.
• Generated output cannot bypass Seedling's human review, verification, and approval gates.

6. Retention and deletion

Connected data

Synchronized Slack records remain while the connection is active and are removed through a durable integration purge after disconnect.

Credentials

Stored Slack credentials or connection secrets and connection-owned synchronization state are deleted from active Seedling systems as part of the purge.

Backups

Deleted information may remain in encrypted, access-restricted backups until expiry, ordinarily within 35 days after active-system deletion.

7. Installation, help, and removal