Salesforce Summer ’26 turns Chatter off by default in new orgs. Admins should check Case Feed, Experience Cloud, APIs, and package dependencies early.
Key takeaways
- New Salesforce orgs created in Summer ’26 start with Chatter turned off.
- Existing orgs are unaffected; only fresh orgs get the new default.
- Case Feed, Experience Cloud, and Chatter APIs fail quietly if it stays off.
- Add "confirm Chatter setting" to your org-creation checklist now.
Salesforce Summer ’26 changes one org setup default that admins should not miss: Chatter starts turned off in new Salesforce orgs.
This is not a Chatter retirement. Salesforce is not turning Chatter off in existing orgs. The change applies to orgs created in Summer ’26 and later, according to the Salesforce Summer ’26 release notes. Salesforce’s admin release countdown lists Summer ’26 production release windows on May 15, June 5, June 12, and June 13, 2026, with admins directed to check the Salesforce Maintenance Calendar for the exact instance date in the Salesforce Admins release countdown.
For admins and ops leads, the risk is not the setting itself. The risk is assuming a new org behaves like the org you configured last year.
Salesforce Summer ’26 Chatter default change
In new orgs created in Summer ’26 and later, Chatter starts disabled. If your implementation needs Chatter-dependent features or Chatter APIs, an admin must turn Chatter on in Setup.
Salesforce’s release note examples include:
- Case Feed
- Chatter in Experience Cloud sites
- Chatter in orgs where Slack is not supported
- Features that call Chatter functionality through APIs
Existing Salesforce orgs are not affected by this default change. If your production org already uses Chatter, Summer ’26 does not remove it. If your sandbox was created before the release, it may not show the same default behavior as a brand-new org created after the release.
That difference matters during implementation work. A team may configure one sandbox, document the setup steps, and then create a new sandbox or production org later. If Chatter is off in the later org, the symptoms may look like missing functionality instead of an org-level setting.
Add this to the org creation checklist. Do not leave it to memory.
Why does Chatter still matter in Salesforce?
Chatter is easy to overlook until a process depends on it.
Service teams often encounter Chatter through Case Feed. Experience Cloud teams may use Chatter for authenticated site collaboration. Admins may also inherit older automation, Apex, or managed packages that expect Chatter objects or APIs to be available.
The issue will not always appear as “Chatter is off.” It may appear as:
- A missing feed on the Case record
- A collaboration option that does not appear in Setup
- A managed package feature that fails during configuration
- An Apex test that references feed objects
- A user acceptance testing issue on an Experience Cloud page
- A support workflow that worked in one org but not another
That is why this change belongs in setup documentation, not release trivia.
Before new build work starts, answer these questions:
- Are we creating a new Salesforce org after the Summer ’26 release?
- Does the implementation use Case Feed?
- Does an Experience Cloud site include feed-based collaboration?
- Do any flows, Apex classes, integrations, or managed packages call Chatter APIs?
- Are users being moved from an older org where Chatter was already enabled?
- Is Slack part of the collaboration design, or does the process still require activity inside Salesforce?
If any answer is yes, confirm the Chatter setting before configuration starts.
What Salesforce admins should check now
Start with org inventory. This change matters most for new builds, fresh sandboxes, trial orgs, and new production orgs created after the Summer ’26 release.
Use this checklist:
- Check new org creation plans. List any Salesforce orgs your team plans to create after the release window for your instance.
- Confirm collaboration requirements. Identify whether Case Feed, Experience Cloud feeds, Chatter groups, feed tracking, or Chatter APIs are in scope.
- Review automation dependencies. Search flows, Apex, integrations, and deployment notes for Chatter-related references.
- Review managed packages. Ask each vendor whether Chatter must be enabled for package setup, support processes, or user features.
- Update build templates. Add “confirm Chatter setting” to org setup documentation.
- Test from a new org. Do not rely only on older sandboxes when validating Summer ’26 behavior.
- Document the decision. If Chatter stays off, record why. If it is enabled, record which feature requires it.
The decision should be explicit. “We forgot to turn it on” is different from “we do not use Chatter.”
How does the Chatter default affect Case Feed?
Case Feed is the first surface to check.
A service team may not describe its process as “using Chatter.” They may say agents use the case feed, post internal updates, review activity, and collaborate on customer issues. Depending on the configuration, that can still connect to Chatter functionality.
Check the exact Case page experience your users need. Name the components and record behavior in the requirement. Avoid vague requirements such as “users can collaborate on cases.”
Write down the specific surface:
- Case Feed on the Case record
- Feed posts
- Internal comments
- Tasks on the Case
- Email-to-Case activity
- Slack notifications
- Flow-created follow-up tasks
- Case comments exposed to external users
These are not interchangeable. They create different records. They have different permission models. They also produce different audit trails.
If Chatter is required for the desired Case Feed behavior, turn it on before user acceptance testing. Otherwise, testers may report a broken support workflow when the real issue is a disabled org setting.
How does the Chatter default affect Experience Cloud?
Experience Cloud deserves its own review.
If your site design includes authenticated user discussion, feed-based interaction, or collaboration inside the portal, confirm whether the feature depends on Chatter in your configuration.
This matters because Experience Cloud requirements often use broad language. A statement like “partners can collaborate on requests” does not tell an admin which Salesforce feature to configure.
Clarify the intended surface before build work starts:
- Is the collaboration happening on a record page?
- Is the user posting to a feed?
- Is the update visible to internal users, external users, or both?
- Does the interaction create a Case Comment, feed item, task, or message?
- Does the process require moderation?
- Does the process need reporting or audit history?
Those answers decide whether Chatter belongs in the design.
If the site does not need Chatter, leave it off and document the decision. If the site does need Chatter, enable it early and include it in the deployment runbook.
What to do if your team uses Slack
Salesforce has been increasing Slack’s role across product releases. The Summer 2026 product release announcement includes Slack-centered work patterns, including sales use cases described in Salesforce’s Summer 2026 product release announcement.
That does not mean every Chatter use case should move to Slack.
Slack is useful for conversation. Salesforce is useful for record context, reporting, field-level security, automation, and process history. A case update that affects service history may belong on the Case. A quick internal discussion may belong in Slack. Some teams need both.
The admin decision should be based on governance, not habit.
Ask one question first: where does the official customer record live?
If the answer is Salesforce, configure collaboration around the record. If the answer is Slack for a specific interaction, document what still needs to return to Salesforce, such as a task, case status update, or internal note.
Do not let a default setting become the architecture.
Recommended Salesforce admin action
If your team is creating any Salesforce org after Summer ’26, add one setup step this week: confirm whether Chatter should be on or off.
Use this short action plan:
- Add “Chatter enabled?” to the org creation checklist.
- Review Case Feed, Experience Cloud, managed packages, Apex, flows, and integrations for dependencies.
- Decide whether Slack replaces any collaboration behavior, or only supplements it.
- Test the relevant workflow in a new Summer ’26 org.
- Record the decision in the deployment runbook.
If your org uses Case Feed, Experience Cloud collaboration, or Chatter APIs, turn Chatter on early and test the dependent process. If your team does not need Chatter, leave it off and document that choice.
The setting is small. The cleanup gets larger when teams find it during testing.