Chatter Notification Tuning

Chatter Notification Tuning

Activate this skill when an admin needs to reduce Chatter feed noise, lower email volume, or rebalance the notification surface across Chatter feed posts, Custom Notifications (bell), and email alerts. The skill is about governance of the notification channel — not authoring new automation.

Before Starting

Gather this context before proposing changes:

• Where the noise comes from. Three sources, three different fixes:
  • Automated feed posts — Flow Post to Chatter actions, Process Builder posts, Apex FeedItem inserts, automated @mentions in feed. Look in Setup → Object Manager → relevant object → Feed Tracking, plus search Flows for "Post to Chatter" actions and Apex for FeedItem inserts.
  • Group activity emails — Member-driven posts in Chatter groups. Per-group Email Frequency controls digest vs per-post.
  • Follower / record-followed emails — Triggered when a user follows a record (manual or auto-follow), tied to Feed Tracking changes.
• Who's complaining. A single noisy executive often drives a full-org tuning project; a quieter pattern is "everyone deletes the digest unread." Both need different responses.
• Do you have Custom Notifications (Notification Builder)? Available since Summer '20. The bell-icon channel is generally a better fit than feed posts for targeted, transient notifications. If the answer is "we never used it," the most-leveraged tuning is migrating high-volume automated feed posts to Custom Notifications.
• License constraints. Chatter Free / Chatter External users have a smaller subset of email-notification controls. Customer Community + Customer Community Plus follow Experience Cloud notification mechanics, not the standard Chatter set.

Core Concepts

Concept 1 — Three control surfaces, layered

Chatter notifications layer like a CSS cascade. Each surface can override the layer above it:

1. Org-level Chatter Settings (Setup → Chatter Settings + Setup → Email Settings → Chatter Email Settings).
   • EnableChatter, EnableEmailNotifications, EnableMyChatterMessages.
   • Sets the default on for new users and the global ceiling — disabling at this level overrides everything below.
2. Group-level Email Frequency on each CollaborationGroup record.
   • Values: Daily, Weekly, Each post, Limited, Never. Limited sends emails only for posts that @mention the user or are in the user's first-degree-followed records.
   • Group owners and admins can change this; non-owner users can only change their own per-group preference under My Settings.
3. User-level Email Settings (My Settings → Email → Email Notifications).
   • Per-user opt-out of bookmark replies, comments on followed posts, group digest choices. The user's settings always override the org default once they touch the page.

The cascade explains why an org-level "turn off chatter emails" doesn't always work — existing users who once saved their Email Notifications page now have a per-user record that pins them on.

Concept 2 — Feed Tracking is what makes records noisy, not Chatter

Feed Tracking on an object/field generates a FeedItem every time a tracked field changes on a record that someone follows. Two failure modes:

1. Tracking too many fields. Tracking LastModifiedDate on Account will generate a FeedItem on every save — usually unwanted. Recommended: track only fields tied to qualitative state (Stage, Owner, Status), never timestamps or rollup fields.
2. Auto-follow is on. Setup → Chatter Settings → "Allow Coworker Invitations" + per-object Auto-Follow rules cause users to silently accumulate followed records. The user later sees floods of automated activity in their feed and has no idea where the follows came from. Audit auto-follow rules early.

To kill noise at the source: prune Feed Tracking to ≤5 fields per object, and disable auto-follow on objects that are mass-edited (Lead, Case).

Concept 3 — Custom Notifications (bell) vs Chatter feed posts

Decision tree for "I want to tell users something happened":

The most-leveraged tuning move in a noisy org is auditing Flow / Apex FeedItem inserts and migrating the transient-alert ones to Custom Notifications. A single Flow that posts a "Stage moved to Closed Won" feed item on every opportunity may produce thousands of FeedItem rows per day; Custom Notifications target the same recipients without the storage and feed-pollution cost.

Concept 4 — Limited digest is underused

Most orgs default group email frequency to Each post or Daily. The Limited setting is the smartest default for collaboration groups:

• Sends emails only for posts that @mention the recipient OR posts that comment on a thread the recipient already participated in.
• Cuts email volume by 80–95% in active groups while preserving the "this involves me" signal.

For broadcast groups (announcements, all-hands), Daily digest is appropriate. For project-specific or interest groups, Limited is almost always the right default.

Recommended Workflow

1. Inventory the noise sources. Run the bundled scripts/check_chatter_notification_tuning.py against your retrieved metadata to enumerate Flows that post to Chatter, Apex classes that insert FeedItem, and objects with Feed Tracking on more than 5 fields.
2. Audit Feed Tracking per object. For each object reported by the checker, open Setup → Object Manager → Feed Tracking. Remove timestamp / rollup / formula fields from the tracking list. Aim for ≤5 qualitative fields per object.
3. Migrate transient automated feed posts to Custom Notifications. Replace each FeedItem-inserting Flow / Apex with a Custom Notification action. Delete or deactivate the original after a 2-week parallel-run window.
4. Set group email frequency defaults. For each CollaborationGroup, decide between Daily, Limited, and Never based on group purpose. Communicate the change to group owners with the rationale.
5. Audit auto-follow rules. Setup → Chatter Settings → User Auto-Follow defaults + any per-object follow automation. Disable auto-follow on mass-edited objects. Existing follows can be cleaned with a one-time EntitySubscription purge.
6. Reset user-level Email Notifications stuck-on state. For users who saved their settings before the org-level change, only they can re-save their Email Notifications page. Communicate the action with a step-by-step screenshot in the change announcement.
7. Re-measure. Two weeks after the change, re-run the checker and pull FeedItem count + EntitySubscription count by date to confirm the curve.

Related Skills

• apex/apex-custom-notifications-from-apex — Custom Notification API patterns, recipient targeting, target page navigation
• apex/apex-connect-api-chatter — programmatic feed manipulation via Connect API
• admin/email-deliverability-strategy — broader email volume management beyond Chatter