Privacy Policy

Overview

This policy describes how the People service (“we,” “our,” or “the service”) processes information when your organization uses it to monitor team activity from Slack, GitHub, and (when enabled) Jira Cloud. The organization that operates this deployment is responsible for configuring the service and deciding what data is collected.

What data we collect

• Account and access: email address, display name, password hash (if credentials sign-in is used), organization membership, and role within the product.
• Slack (when connected): workspace identifiers (team ID and name), bot tokens issued by Slack for your workspace, and — for public and private channels that a workspace administrator explicitly adds the People bot to — channel IDs, channel names, and whether the channel is private (no channel topics, purposes, or membership lists). For Slack users an administrator configures as monitored, we store their Slack user ID, display/real name, avatar URL, and metadata-only activity signals: event timestamp (ts), channel ID, event subtype, reaction name (for reaction_added), and presence state. We do not store or process Slack message content, blocks, attachments, uploaded files, links, edited/previous message bodies, thread content, or the content of any reacted-to message. We also do not observe direct messages (DMs) or multi-person DMs: the Slack scopes im:history and mpim:history are intentionally not requested.
• GitHub (when configured): repository identifiers your organization watches, commit metadata (e.g. SHA, author, message, timestamps, line stats where available), and pull request metadata (e.g. title, state, authors, dates).
• Jira Cloud (when connected): OAuth tokens for your Jira site, Jira user identifiers (accountId) and display names for people your organization maps to internal profiles, webhook payloads and REST-derived issue metadata (for example issue keys, summaries, status, story points when configured), and activity events derived from those sources.
• Technical data: standard server logs and security-related metadata needed to operate the service (e.g. request timestamps, error diagnostics), as typical for web applications.

If the service receives data from Slack, Jira, or other integrations but does not use it for a product feature, that may still occur through normal API or logging behavior; we design the product to use only what is needed for the features your organization enables.

How we use data

We use the information above to provide the service: dashboards, analytics, notifications, retention and cleanup, authentication, and security. We do not sell your personal information, and we do not share it with third parties except infrastructure sub-processors (hosting and database providers) that operate the deployment. We do not use any Slack, GitHub, or Jira data to train large language models. Because Slack message content is discarded at ingestion (see below), such content cannot be used for any purpose — including analytics, export, backup, or model training.

How long we keep data

Activity data is retained according to your organization’s retention settings in the product (for example, a configured number of days for events), after which it may be deleted automatically. Account and configuration data are kept while your organization uses the service and for a reasonable period afterward for legal, security, or backup purposes unless your organization requests earlier deletion, subject to applicable law.

Security

Integration secrets (such as tokens) should be stored using the service’s encryption capabilities where enabled. You should protect administrator credentials and follow your organization’s security policies. Traffic to the service should use HTTPS (TLS).

Data deletion requests

Organization data: an organization OWNER can delete the entire organization from organization settings; that removes organization-scoped activity and configuration from our database.

Your login account: contact the operator of this deployment using the email below. We verify your identity (for example, that the request comes from your registered email or an owner of your workspace). We aim to acknowledge requests within two business days and complete verified account deletion within 30 calendar days where feasible. If you are the only owner of an organization, we may need to delete or transfer that organization before removing your account.

Your rights and requests

Depending on your location, you may have rights to access, correct, delete, or export personal data, or to object to or restrict certain processing. To exercise these rights:

• If your employer or organization operates this People deployment, contact your internal administrator or IT team first.
• You may also contact the team operating this instance at support@wepeople.app regarding access, portability, or deletion requests.

Changes

We may update this policy from time to time. The “Last updated” date at the top will change when we do. Continued use of the service after changes means your organization accepts the updated policy where permitted by law.

Atlassian (Jira Cloud)

Where this deployment stores Atlassian-related personal data (such as a user's Jira accountId linked to a monitored profile), the operator configures an automated job that reports those accounts to Atlassian's Personal Data Reporting API on a recurring basis, as required for OAuth 2.0 (3LO) apps that store such data. Atlassian may instruct the service to refresh or remove stored identifiers; the integration applies those instructions. End users can see which Atlassian Marketplace or linked apps report storage of their data in their Atlassian account settings; see Atlassian's user privacy guide for app developers.

Slack scopes and data boundary

When Slack is connected, the People app requests a minimal, fixed set of bot token scopes and uses each one for a specific product feature:

• channels:history and groups:history — receive message.channels and message.groups events so we can record that a monitored user was active. All message content (text, blocks, attachments, files, edited/previous bodies) is discarded at the HTTP handler boundary and never logged, stored, displayed, or forwarded.
• channels:read and groups:read — resolve channel IDs (for example C0123ABC) to channel names on the engagement timeline, and list channels in Settings → Slack → Channels so an admin can decide which channels the bot should observe. We store only channel ID, channel name, and whether the channel is private.
• channels:join — allow an administrator to add the bot to a selected public channel with one click (conversations.join). This is the sole action this scope enables. Private channels are not covered by this scope and still require a human /invite @people from inside the channel.
• users:read — call users.getPresence for monitored users on a schedule, and call users.list inside the Settings UI so an administrator can choose which workspace members the organization wants to observe. We do not request users.profile:read or users:read.email.
• reactions:read — subscribe to reaction_added. We record only the fact that a monitored user reacted (Slack user ID, channel ID, reaction name, item timestamp). We do not fetch, read, or store the content of the reacted-to message.

The following Slack scopes are intentionally not requested and will never appear on the OAuth consent screen: im:history, mpim:history, im:read, mpim:read, channels:manage, groups:write, users.profile:read, users:read.email, and incoming-webhook. Direct messages, multi-person DMs, and channel content are therefore not visible to, or recoverable by, the People app.

A workspace administrator can disconnect Slack at any time from Settings → Integrations → Slack. On disconnect the stored bot token is revoked and channel records are removed from the organization.

Slack Marketplace

If this app is listed or distributed via Slack, we aim to follow Slack’s expectations for privacy disclosures and data handling. See Slack’s app guidelines (privacy policy requirements).