Skip to content

Slack Data Handling

This page describes what the ThinkWork Slack workspace app processes, where that data is stored, and how operators can explain the integration to enterprise IT and compliance reviewers.

ThinkWork processes Slack data only when a user invokes the app through a supported Slack surface:

  • @ThinkWork mention
  • direct message to the ThinkWork bot
  • /thinkwork slash command
  • message shortcut
  • Post to channel promotion on an already-generated ephemeral response

The app does not continuously ingest workspace history. It does not index all Slack channels. It does not train models on Slack content.

For an invoked turn, ThinkWork builds a Slack task envelope containing:

DataPurpose
Slack team id and workspace row idResolve the installed tenant workspace and bot token.
Slack channel id and thread timestampPreserve where the response should return.
Invoking Slack user idResolve the linked ThinkWork requester.
Selected shared Computer idRoute work to an assigned shared Computer without a personal Computer fallback.
Source message text and timestampGive the Computer the user’s actual request.
Summarized source-thread messagesProvide relevant local context for the request.
File references from the source messageLet the Computer reason about attachments the user explicitly included.
Slack delivery metadataStore response_url, placeholder timestamp, or modal id so the dispatcher can deliver the final answer.

Messages outside the invoked thread are not included. If thread fetch fails, the task still proceeds with the source message and an empty thread context.

ThinkWork stores Slack integration state in the customer’s AWS account:

  • slack_workspaces: workspace install metadata, bot user id, status, and Secrets Manager path.
  • slack_user_links: per-user Slack-to-ThinkWork account bindings.
  • slack_threads: Slack-to-ThinkWork thread/message mapping.
  • computer_tasks: the normalized Computer task envelope and response state.
  • computer_events: dispatch, failure, and attribution-degradation events.
  • Secrets Manager: Slack app credentials and per-workspace bot tokens.

Slack bot tokens are not committed to the repo or stored in Terraform variables. Lambda environment variables contain secret ARNs/paths, not token values.

Slack content enters the same tenant-scoped Computer runtime as ordinary ThinkWork thread turns. The runtime can use the selected shared Computer’s memory context, approved tools, and the requester’s scoped personal context under the same tenant and user boundaries that apply outside Slack.

Slack content is not used to train foundation models. Provider-specific retention and no-training controls follow the deployed Bedrock/AgentCore configuration for the customer’s AWS account.

ThinkWork is AWS-native. The Slack app, task storage, runtime, and dispatch path run in the customer’s configured AWS region and account. For current deployments, ThinkWork operators should describe the Slack app as US-region processing unless the stage has been explicitly provisioned elsewhere.

Slack itself may process and store Slack workspace data under the customer’s Slack agreement. ThinkWork’s disclosure covers only the data after Slack sends an invocation to the ThinkWork app endpoint.

  • Workspace installation is tenant-admin controlled.
  • User linking is per-user; an admin workspace install does not automatically let every Slack user invoke a Computer.
  • Computer access is assignment-based through direct user and Team assignments.
  • Runtime task creation uses the linked ThinkWork user id, not the Slack display name alone.
  • The Slack dispatcher reads the bot token only from the tenant-scoped Secrets Manager path associated with the installed workspace.

Uninstalling the Slack app or revoking the bot token prevents new Slack delivery. Existing audit and Computer task records remain for traceability according to the customer’s retention policy. Operators can mark a workspace revoked and ask users to re-install/re-link when Slack returns authentication errors.

ThinkWork’s Slack app is an on-demand invocation surface. It processes only messages a user explicitly invokes from, stores tokens in Secrets Manager, routes work through tenant-scoped Computer tasks, and preserves attribution in Slack even when optional identity customization is unavailable.