This FAQ covers the most frequently asked questions about the Slack integration for Data Quality Alerts.
Is the App developed by the vendor (Slack)?
No, the application is developed by Snowplow. It is not published on the Slack App Directory/Marketplace and is a custom integration specifically designed for our customers.
Does it use Modern Auth / Okta / OAuth?
Yes, the application uses OAuth 2.0 flow following Slack's recommended best practices. When a user connect their Slack workspace through Snowplow Console the browser initiates a request to Console API which generates a state parameter and stores the mapping before redirecting to Slack's OAuth URL. After the user authorises the app in their Slack workspace, Slack redirects back to our callback endpoint to Console API with an authorisation code and state.
The Console API validates the state parameter to prevent CSRF attacks, exchanges the code for an access token through M2M communication with Slack API, and immediately stores the returned access token and team information in HashiCorp Vault following same security policies as the rest of customer secrets. Only Vault path reference is stored in Console API database, never actual tokens. This ensure tokens never reach the browser and are securely isolated.
Are communications internal to the specific organisation?
The data flow follows this sequence: Console API, deployed on Snowplow infrastructure, periodically polls Data Quality API which is deployed on customer infrastructure along with the loader as an add-on the customer opt-in. This communication follows strict OAuth flow with custom scopes implemented through Auth0 (Otka), following the same authentication patterns as the Console API. Each JWT token issued by Auth0 is scoped specifically to one customer, preventing any cross-customer access.
Are secure protocols used?
Yes, all communication use secure protocols (HTTPS/TLS) throughout the entire data flow, Console API <-> Data Quality API communication uses AuthO customer-scoped JWT tokens. The Console API <-> Slack API uses Slack OAuth tokens. Authentication and authorization are guaranteed through these OAuth flows, with tokens never exposed in URL's or logs and with expiry in place. All OAuth flows follows industry best practices for secure token exchange.
Is there a possibility of PCI / PII being accessed by the plugin?
No, we implement PII filtering at the customer edge before any data leaves customer infrastructure. Data Quality API (deployed on customer's infrastructure) uses template-based filtering for error messages, which is the only data that could potentially contain PII, specifically matching against json-schema-validator templates from: json-schema-validator/src/main/resources/jsv-messages.properties at 6c379356799b61c20c5fefb154b22125b30b7baa · networknt/json-schema-validator. Any error message field that could contain PII is matched against these template, and if there's no match with any template, the entire message is redacted. This ensures that only known, safe error patterns are transmitted to Snowplow Console API.
Additionally, no failed events information is stored at any point during the data flow within our systems. The Console API only stores the Slack access token in Vault per customer-workspace authorisation and the list of authorised channels. No failed event data is persisted. Only metadata about errors is transmitted to Slack channels in the customer's own workspace, not eh actual PII/PCI data. The integration only requests minimal Slack scopes (chat:write, channels:read, groups:read), avoiding broader scopes like users/read or files:read.
Is there a process for reviewing new features of the plugin before updating?
Yes, both Data Quality API and Console API follow string CI/CD workflows with mandatory peer code reviews for all developments before deployment.
Is there data flow from the plugin to a third-party vendor (other than the SaaS vendor)?
The data flow follows this path: Console API polls Data Quality API on customer infrastructure, Data Quality API responds with PII-filtered failed events to Console API on Snowplow infrastructure, then Console API sends formatted messages to Slack API. No data is stored during this flow except for the Slack access tokens in Vault per customer-workspace and the list of authorised Slack channels. No other third-party vendors are involved in the data flow.
Is the solution actively developed?
Yes, the solution is actively developed and maintained by our engineering team.
Is the solution patched when security vulnerabilities are identified?
Yes, our CI/CD workflows on all involved repositories include automated vulnerability scanning using Snyk. As part of our development flow, we run Snyk scans and any High or Critical vulnerability detected are address with maximum priority. Additionally in July 2025 we underwent a pentest audit, which involved 14 days of testing by Cure53. The audit covered both Console API and Data Quality API. Any identified vulnerabilities are prioritised and patched according to severity, with Critical and High severity issues receiving maximum priority for immediate resolution.
Are SAST / SCA / Vulnerability management tools used to detect security vulnerabilities?
Yes, we use Snyk integrated into our CI/CD workflows. Our security policy mandates that Critical and High vulnerabilities receive maximum priority.
What bot scopes are required?
The minimum required scopes for the Slack integration to work are:
- channels:read -> We need to list public channels from Console UI so users can select which channel they want Snowplow Notification App to send failed events messages. (Only apply to public channels)
- groups:read -> Needed to list private channels the app has been invited, allowing to post messages to them.
- chat:write -> Needed to post failed events messages to a channel.
When a user integrates Snowplow Notifications App with the workspace for the first time they are prompted with the scopes required.
Is there a GitHub repo to the source for security review?
Both Data Quality and Console API repositories are private.
Does the plugin follow data retention and privacy policies?
No failed events are stored at any point in the data flow—neither in the Console API nor in the Data Quality API. PII-filtered failed events are sent only to the customer’s Slack workspace channels. This means the data is effectively stored only in the customer’s data warehouse, where the original failed events reside, and in the customer’s Slack channels, where only the PII-filtered versions are posted.
Does the plugin have adequate logging to detect and investigate security incidents? Is there a mechanism for monitoring plugin activity for suspicious behavior?
The Data Quality API, when deployed on customer infrastructure, includes built-in observability features. This includes Sentry, which is configured to capture and send traces when failures occur, providing robust error tracking and alerting capabilities.