TechPrufer
Get started
Slack
Slack logoSlack · Feature trail

Email Classification for Slack Connect

2 posts · Oct 2020 – Jul 2021

What this trail covers

This thread tracks the evolution of Slack's email classification system, designed to predict whether an invited email address belongs to an internal employee or an external collaborator. Initial posts detail the foundational architecture and the challenges of accurately classifying emails at scale to guide users towards the appropriate invite mechanism (Workspace Invites vs. Slack Connect). This post details the Email Bridge feature, which allows invited users to receive notifications via email and respond to Slack messages using email alone, enabling collaboration before account activation. It also covers the architecture of the Email Bridge, including discoverability of invited users, an email interoperability service for sending notifications and routing replies, and lessons learned regarding gradual rollout, instrumentation, and turning a proof-of-concept into a production feature. Future work includes extending email reply functionality to existing users and delivering relevant Slack messages and team updates to invited users via email.

All Slack trails
  1. Email ClassificationThis post details the technical implementation of Slack's Email Classification engine. It describes the classification logic using three data sources: Settings Context (O(1)), Inviter Context (O(1)), and Team Context (database round-trip per domain). The Team Context utilizes Vitess to store aggregate domain counts per team, grouped by role, in a `domains` table. It explains how domain thresholds (e.g., 10% of employees) are used to classify domains as internal or external. The post also outlines an eventually-consistent architecture involving 'Mutate Jobs' for real-time updates to domain counts via UPSERT operations in Vitess, and a 'Healer' component to address data drift caused by asynchronous job queues. Examples illustrate handling user joins, role changes, and deactivations, highlighting the challenges of out-of-order operations and the eventual consistency of the system.
  2. Bridging the Gap Between Slack and Email UsersThis post details the architecture and implementation of the 'Email Bridge' feature, which bridges the gap between Slack and email users. It introduces the concept of 'Invited members' with a specific flag to indicate unaccepted invitations, making them visible in search and for @mentions. The core of the feature is the 'Email interoperability service' which batches messages into emails for invited users and routes their email replies back to the appropriate Slack channel using a unique Reply-To address and AWS SES/SNS. The post also discusses lessons learned from expanding the feature to Enterprise Grid, the importance of instrumentation, and the strategy of shipping a proof-of-concept quickly and then refactoring.