ChatterSettings Metadata Type in SFDX

Architectural Overview#

The ChatterSettings metadata type is the master control plane for Salesforce Chatter collaboration across internal Lightning Experience apps, Service Cloud Case Feeds, and Experience Cloud (Network) sites. Stored as Chatter.settings-meta.xml, it controls feed post mutability (enableFeedEdit), unlisted group privacy (enableUnlistedGroups), rich link metadata fetching (enableRichLinkPreviewsInFeed), and records sharing via Chatter groups (allowRecordsInChatterGroup).

From a security and compliance standpoint, ChatterSettings directly impacts data governance. For example, financial services and healthcare architects often disable enableFeedEdit or allowCustomerInvitations via Chatter.settings-meta.xml so that feed posts remain immutable for regulatory compliance and external guests cannot be invited ad-hoc outside governed Experience Cloud portals.

Directory Location and File Suffix#

In Salesforce DX source format, ChatterSettings is stored in the settings directory as Chatter.settings-meta.xml.

Key Metadata Fields#

The following table highlights the primary configuration flags on ChatterSettings in API version 68.0 (Winter ’27):

Declarative Metadata Example#

The following Chatter.settings-meta.xml configures enterprise-hardened Chatter settings: enabling feed pinning, unlisted groups, out-of-office status, and record associations in groups, while blocking ad-hoc external customer invitations (<allowCustomerInvitations>false</allowCustomerInvitations>).

<?xml version="1.0" encoding="UTF-8"?>
<ChatterSettings xmlns="http://soap.sforce.com/2006/04/metadata">
    <allowChatterGroupArchiving>true</allowChatterGroupArchiving>
    <allowCustomerInvitations>false</allowCustomerInvitations>
    <allowRecordsInChatterGroup>true</allowRecordsInChatterGroup>
    <enableApprovalRequest>true</enableApprovalRequest>
    <enableChatter>true</enableChatter>
    <enableChatterEmoticons>true</enableChatterEmoticons>
    <enableFeedEdit>true</enableFeedEdit>
    <enableFeedPinning>true</enableFeedPinning>
    <enableInviteCsnUsers>false</enableInviteCsnUsers>
    <enableOutOfOffice>true</enableOutOfOffice>
    <enableRichLinkPreviewsInFeed>true</enableRichLinkPreviewsInFeed>
    <enableTodayRecsInFeed>false</enableTodayRecsInFeed>
    <enableUnlistedGroups>true</enableUnlistedGroups>
</ChatterSettings>

Package Manifest (package.xml)#

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <types>
        <members>Chatter</members>
        <name>Settings</name>
    </types>
    <version>68.0</version>
</Package>

SFDX CLI Retrieval and Deployment#

Retrieve and deploy ChatterSettings using the Salesforce CLI (sf):

# Retrieve ChatterSettings into force-app/main/default/settings/Chatter.settings-meta.xml
sf project retrieve start --metadata Settings:Chatter

# Deploy ChatterSettings to the target org
sf project deploy start --metadata Settings:Chatter

Architect Best Practices and Gotchas#

• Dependency with allowInChatterGroups: If a CustomObject specifies <allowInChatterGroups>true</allowInChatterGroups>, allowRecordsInChatterGroup in ChatterSettings must be true in the target org.
• Compliance & eDiscovery Immutability: In FINRA or SEC-regulated environments where communications cannot be altered after publication without an audit log, either set <enableFeedEdit>false</enableFeedEdit> or ensure your compliance archiving tool queries the FeedRevision object via SOAP/REST API.

Frequently asked questions

How is ChatterSettings referenced in package.xml and SFDX source format?

In package.xml, specify Settings as the type and Chatter as the member. In SFDX source format, the file is stored at force-app/main/default/settings/Chatter.settings-meta.xml.

Why should architects disable allowChatterGroupArchiving in certain compliance orgs?

In regulated orgs that run automated legal hold or eDiscovery jobs against CollaborationGroupfeeds, controlling group archiving ensures active audit processes behave predictably.

What is the security risk of enabling allowCustomerInvitations in ChatterSettings?

Enabling allowCustomerInvitations lets users invite external users with email domains outside your company into private Chatter groups, which should be disabled if external collaboration is strictly governed through Experience Cloud.

What happens if enableChatter is set to false in an org with Experience Cloud or Case Feed?

Salesforce blocks disabling Chatter if features that depend on it, such as Experience Cloud sites, Case Feed, or Feed Tracking on objects, are active in the target org.