Data retention policy
Parallel reads Slack content only when a user @mentions the bot, replies in such a thread, sends it a direct message, or runs its slash command. That content (the message and, for a follow-up, the thread it sits in) is sent to Parallel's API to produce the answer and is not persisted by the Slack app: our Slack database stores only identifiers and status -- workspace, channel, thread and message timestamps, the requesting user's Slack ID, monitor definitions (the topic to watch and its cadence) and delivery state. Session, usage and diagnostic metadata is retained for operational purposes as described in our Customer Terms. API-side request/response handling follows the customer's Parallel data-retention tier; customers can opt into limited or zero data retention, under which request and response content is not retained. Monitor definitions persist for the life of the monitor and are retained for audit after cancellation. Use of request content to improve Parallel's models is governed by the customer's Parallel agreement and data-retention tier: content used for improvement is never linked to an individual, and customers on limited or zero-data-retention tiers have no request or response content retained, so none is available for model improvement. Slack data is never used to train third-party models. Slack data never trains or improves any model, Parallel’s own included, whatever the customer’s tier.
Data archiving and removal policy
Uninstalling the app or revoking its token disconnects the workspace immediately: the installation is marked revoked and the app's own credential is revoked on our side within seconds. Workspace-scoped records (installation, monitors, delivery state) are deleted on request via support@parallel.ai. Individuals may request access to, correction, portability or deletion of personal data at support@parallel.ai, per https://parallel.ai/privacy-policy. Data storage policy
All data is encrypted in transit (TLS 1.2+) and at rest. Slack app state is stored in Google Cloud Spanner in the United States; bot OAuth tokens are encrypted at the application layer with a key held in Google Secret Manager, in addition to encryption at rest. Slack request signatures are verified on every inbound request. Access to production data is restricted to authorized engineers.
App/service has sub-processors
yes
Guidelines for sub-processors
App/service uses large language models (LLM)
yes
LLM model(s) used
GPT-5-class
LLM retention settings
Model providers retain no prompts or completions. Parallel API retention follows the customer's tier; limited/ZDR tiers retain no request or response content. The Slack app stores only identifiers, monitor definitions and delivery status.
LLM data tenancy policy
Multi-tenant, with per-organization isolation. Providers use ZDR and do not train on Slack data. Slack data never trains or improves any model, Parallel’s own included, whatever the customer’s tier.
LLM data residency policy
Slack requests are processed in the US (Google Cloud, us-central1), with inference by US-based model providers. The Slack app uses the US endpoint, not the EU Search API endpoint.