Skip to content

title: Slack Notifications 2.0 type: system created: 2026-04-24 updated: 2026-04-24 tags: [slack, notifications, preferences, preference-system, user-settings, cross-platform, desktop, mobile, read-time-translation, schema-decoupling] sources: [2026-03-19-slack-how-slack-rebuilt-notifications] related: companies/slack, concepts/read-time-preference-translation, concepts/preference-schema-decoupling, concepts/cross-platform-preference-parity, patterns/read-time-schema-translation, patterns/decouple-what-from-how-in-preferences, patterns/unified-preference-model-for-cross-client-state

Slack Notifications 2.0

Slack Notifications 2.0 is the internal name for the rebuild of Slack's notification-preference system, shipped without a disruptive database-level migration via a read-time translation layer mapping legacy preference values to new-world semantics. Canonicalised in the 2026-03-19 Slack Engineering post How Slack Rebuilt Notifications.

Legacy state (before)

Four conflicting preference axes across clients:

'desktop': everything | mentions | nothing   // Push on desktop
'mobile':  everything | mentions | nothing   // Push on mobile

Each axis conflated content selection (what to notify about) with delivery channel (push on/off) into a single enum. "A 'nothing' setting on mobile meant something entirely different from 'Off' on desktop." Settings did not reliably sync across clients; advanced controls were scattered across multiple menus.

New state (after)

Three preferences with orthogonal axes:

'desktop':             everything | mentions   // Activity on desktop and mobile
'desktop_push_enabled': true | false           // Push on desktop
'mobile':              everything | mentions | nothing  // Push on mobile
  • Activity (in-app badges, counts) is consistent across clients — driven by desktop.
  • Push is independently controllable per platform via desktop_push_enabled (desktop) and mobile (mobile).
  • Advanced controls (mobile-specific badges like "badge all unreads") live in a dedicated hierarchy level and no longer compete with primary preferences for discovery.

User-facing hierarchy

What to notify you about:   All new messages
                            Mentions and DMs (default)
                            Mute

Push notifications:         desktop and mobile (default)
                            desktop only
                            mobile only
                            disabled

Advanced:                   mobile-specific customization
                            badge controls

Migration architecture

The load-bearing decision: no database-level migration. Slack explicitly rejected "move everyone from 'off' to 'mentions' at the database level" on rollback-safety grounds and chose a read-time translation approach instead (patterns/read-time-schema-translation).

  1. Additive write: a new desktop_push_enabled boolean preference is introduced. Every existing user is backfilled based on whether they previously had desktop: 'off' — these users get desktop_push_enabled: false; everyone else gets desktop_push_enabled: true. This is write-once, no user-visible change, and fully reversible because the legacy desktop value is untouched.
  2. Read-time translation: at every read site, the legacy desktop: 'off' value is interpreted as desktop: 'mentions' + desktop_push_enabled: false — exactly the behaviour "as it functions today." The new-world code never has to special-case "off" because the translator returns clean unified values.
  3. Fallback guarantee: "push_enabled: false always means 'no push,' even during rollbacks." The translator is the safety net for version skew between clients and between client/server — in-flight rollbacks don't reset users' push status.

Cross-platform parity

Mobile (iOS + Android) was rewritten to match desktop structurally and visually. Slack re-platformed "some of the oldest pages in Slack's iOS app — built before our modern architecture" specifically to support the new shared preference hierarchy. The post cites React-based "reusable React components" replacing legacy mobile-specific UI code in the modal — same schema, same structure, same copy across platforms.

Auto-save replaces the legacy save-button pattern. "Users would configure settings, forget to save, and wonder why nothing changed." With auto-save + decoupled activity/push, the user can freely explore the space ("Want to see all activity but only get pushed for mentions?") without incurring a "did my change take effect?" support ticket.

Data integrity failure mode (disclosed)

Slack discloses one production incident during the migration: "A malformed field once reset preferences to Mentions until we cleaned data and flushed memcache." Resolution was data cleanup plus memcache flush. Surfaces a preference-system failure shape relevant to any heavily-cached user-setting store: thin validation + aggressive caching + default-value fallback can compound into a silent preferences-reset event affecting many users simultaneously.

Results (disclosed)

  • Settings-page engagement 5× increase post-launch, sustained for weeks — framed as ongoing active preference refinement, not one-time curiosity.
  • Support burden decreased significantly on notification tickets (specifically the "why am I getting notifications?" / "how do I turn off mobile push?" categories).
  • Push-toggle adoption "higher than expected" — decoupled desktop/mobile push controls drove immediate user uptake.
  • Majority of users chose Mentions and DMs as default post-migration; All new messages and Mute served niche use cases.
  • Fewer per-channel overrides needed post-launch — better global defaults pushed users away from per-channel customisation as a workaround.

What's not disclosed

  • Absolute user count migrated; rollout cadence and region staging.
  • Where the read-time translator lives (server? client? both?); client-version-skew handling.
  • Which storage backend the preferences sit in; caching architecture beyond the memcache flush reference.
  • Data-integrity incident root cause (which field was malformed, detection latency, scope of affected users, what validation was added afterwards).
  • Rollback window: is desktop: 'off' still a valid stored value, or has it been opportunistically migrated on subsequent writes?
  • Post-launch CX-ticket quantitative delta.
Last updated · 470 distilled / 1,213 read