Salesforce Is Removing Session IDs from Outbound Messages: What Admins Need to Know (and Do)

Salesforce has announced a security update that will remove session IDs from Outbound Messages on February 23rd, 2026. This update can have real consequences for orgs that rely on legacy outbound message integrations.

The good news? This change is narrowly scoped and very manageable if you know where to look. Skip to the end of this article for an easy to follow admin check-list that will have your org ready for this change in no time.

What’s Changing?

As part of Salesforce’s ongoing commitment to improving platform security, Salesforce is eliminating the ability to include Session IDs in Outbound Messages.

Specifically:

  • The “Send Session ID” checkbox will be removed from Outbound Message configuration

  • The IncludeSessionId API flag will be ignored and always set to FALSE

  • Existing outbound message payloads will no longer include <sessionId> values

This applies to Outbound Messages only, not to Salesforce APIs more broadly.

Why This Matters

Historically, outbound messages could include a session ID that allowed the receiving system to:

  • Authenticate back to Salesforce

  • Make follow-up API calls

  • Avoid implementing a full OAuth authentication flow

Once this change is enforced, session IDs will simply stop being sent. If an endpoint expects a session ID and has no alternative authentication method, the result can be:

  • Failed authentication

  • Broken integrations

  • Disrupted automations and business processes

The risk isn’t theoretical, it’s binary. Either the endpoint is OAuth-ready, or it isn’t.

Scope Clarification: This Is Only About Outbound Messages

It’s important to be clear about what is and isn’t affected.

This change applies only to:

  • Workflow Rule Outbound Messages

  • Process Builder Outbound Messages

  • Flow Outbound Message actions

It does not impact:

  • Standard Salesforce APIs

  • Apex callouts using Named Credentials

  • OAuth-based integrations

  • Platform Events, CDC, or Streaming APIs

For most orgs, reviewing outbound messages that have “Send Session ID” enabled is excellent coverage.

Admins do not need to conduct a broad integration audit beyond this unless they already know session IDs are in play elsewhere, for example downstream or upstream of an apex built integration.

What About Apex?

Short version: Apex is very unlikely to be impacted.

This update does not change how Apex authenticates or how session IDs work inside Salesforce. Apex code, Apex REST endpoints, and Apex callouts continue to function as they do today.

Where Apex can be indirectly involved is when:

  • An outbound message triggers an external system

  • That system uses the session ID to authenticate back to Salesforce

  • Apex is then invoked via API

In that scenario, the integration breaks because authentication breaks, not because Apex changed.

For most orgs, no Apex changes are required, especially if:

  • Inbound integrations already use OAuth

  • Outbound callouts use Named Credentials

Required Path Forward: OAuth 2.0

Salesforce’s recommended solution is clear: move from session-based authentication to OAuth 2.0.

  • Internally owned endpoints must authenticate using OAuth to obtain access tokens

  • Third-party vendors must update integrations to support OAuth

  • Session-based authentication via outbound messages is no longer supported

Admin Preparation Checklist

If you want high confidence with minimal effort, this checklist gets you there.

1. Identify Outbound Messages Using Session IDs

  • Go to Setup

  • Search for Outbound Messages

  • Review all outbound messages

  • Flag any with “Send Session ID” enabled

For most orgs, this step alone identifies 100% of the risk.

2. Review Each Endpoint

For each flagged outbound message:

  • Identify the endpoint URL

  • Determine ownership (internal vs vendor)

  • Confirm whether it calls back into Salesforce

3. Update Authentication

  • Internally owned endpoints: Implement OAuth 2.0 authentication

  • Vendor-owned endpoints: Contact the vendor and confirm OAuth readiness

Salesforce guidance:

4. Test in Sandbox

  • Validate outbound messages still fire

  • Confirm endpoints authenticate successfully

  • Ensure downstream processes continue working

5. Monitor After Enforcement

After the change in February 2026:

  • Monitor integration logs

  • Watch for authentication errors

  • Validate critical automations

Final Thoughts

This update is part of Salesforce’s broader move toward modern, secure integration patterns, and it’s a good one.

The key takeaway for admins:

  • This is scoped to Outbound Messages

  • Checking for outbound messages with session IDs enabled is strong coverage

  • Apex is almost never directly impacted

  • OAuth-based integrations are already safe

If you review outbound messages now and modernize any legacy endpoints, this change should be a non-event rather than a fire drill.

Ready to Measure and Drive Adoption?

Curious what your users are actually doing in Salesforce all day? Struggling to capture meaningful metrics on user adoption and usage of the platform? RecordWatch is the first fully Salesforce native solution available on the Salesforce AppExchange that was designed specifically for admins, managers, and leadership to measure and drive Salesforce adoption!

Check out our on-demand demo to learn how RecordWatch can help your organization measure and drive Salesforce adoption.

Next
Next

Unlock Deeper Salesforce Adoption Insights with RecordWatch’s New “View Source” Data