Did something change around June 7 that could affect Messenger → Salesforce case creation?

One lead worth starting from: June 7 coincides with the Salesforce Summer ’26 production release weekend — which makes a release-side change a natural first thing to rule out. What follows is an exploration of where to look, meant to help Hayley’s team and their Fin/Salesforce admins get to the bottom of it — not a diagnosis.

Fin ↔ Salesforce Symptom since ~June 7, 2026 Session · 2026-07-06

How to read this This was put together from a summary of the office-hours conversation, so I don’t have the full picture of the setup. Treat it as a map of candidate causes and things to check — a starting point for the people with hands on the org (Hayley’s team + the Fin and Salesforce admins) to confirm or rule out, not a verdict.

The symptom (as I understood it)

Customer emails a software-specific address or uses Messenger in Communities → Fin responds and pulls the right Knowledge articles → should escalate per Guidance → email escalates to the correct queue (still working), but Messenger escalation appears to have stopped creating Cases in Salesforce around June 7 — reportedly with no changes on your side.

The clue worth leaning on Email fine, Messenger not. If that holds up, it suggests the two paths are different mechanisms — and only the API-driven one is affected. That’s a useful place to point the investigation.

Why the date is worth a look

Salesforce’s Summer ’26 production release rolled out on the weekends of May 9, June 5, and June 12, 2026. June 7 is the Sunday of the first production wave. When something “worked at testing and launch, then stopped around the release weekend with no changes on our side,” a release auto-enforcing a change you were opted into by default is a common enough pattern that the release is a sensible first place to look. Summer ’26’s headline theme is “enforced security,” which is why the candidates below lean that way.

One thing to set aside early Worth noting so nobody spends time on it: this likely isn’t the old API-version 21.0–30.0 retirement (that was Summer ’25). The next retirement, 31.0–40.0, isn’t deprecated until Summer ’27 and doesn’t fail until Summer ’28. For a June 2026 change, the Summer ’26 security enforcements below are the more relevant place to look.

Candidate causes to explore — roughly ranked

These are hypotheses to test against the org’s own logs, not conclusions. In rough order of how well each fits the “email works, Messenger doesn’t” pattern:

Legacy connected-app / OAuth flow enforcement

If Fin authenticates to Salesforce via a legacy Connected App using the OAuth username-password (or SOAP login) flow, Summer ’26’s phase-out / usage-restriction enforcement could break that auth path — and it would affect the API create-Case path while leaving inbound Email-to-Case (a separate mechanism) working. That would match the split described, which is why it’s worth checking first.

What to look for: INVALID_SESSION_ID / auth failures in the integration user’s Login History.

Apex user-mode & stricter sharing defaults (API 67.0)

Summer ’26’s headline developer change: “system-level access is no longer assumed — object, field, and sharing rules are enforced by default.” If the case-creation path runs in the stricter mode, the integration user may no longer have the implicit permission to insert a Case it had at launch. Worth confirming whether this path was affected.

What to look for: INSUFFICIENT_ACCESS_OR_READONLY / FIELD_INTEGRITY_EXCEPTION.

Experience Cloud / Communities record-access tightening

Because these cases originate from Communities, if they’re created in a guest/community-user context, the tighter sharing & profile-visibility defaults in Summer ’26 could block the insert silently — the Case just never appears. A candidate if #1 and #2 don’t pan out.

What to look for: guest/community user create failure on the Case object.

A question that could narrow it quickly

“Does the Fin → Salesforce integration authenticate via a Connected App using the OAuth username-password (or SOAP login) flow — or via an External Client App / Named Credential?”

If it turns out to be a legacy connected app / username-password flow, candidate #1 moves up the list, and the likely fix is migrating that auth to a supported flow (External Client App). Either way, the answer helps point the admins in a direction.

A few checks that would confirm or rule these out

Confirm the org’s Summer ’26 upgrade date. status.salesforce.com → your My Domain / instance → Maintenance tab → filter Major Release → Summer ’26. If it landed ~June 5–7, that supports the timing theory (and if it didn’t, that’s useful too — it points elsewhere).
Reproduce one Messenger escalation and read the integration user’s Debug Log + Login History. The error class is what actually distinguishes #1 / #2 / #3 — this is the step that turns hypotheses into an answer.
Setup → Connected Apps OAuth Usage for the Fin app — see whether API calls dropped off around June 7.
Identify what actually creates the Messenger case (the Fin/Intercom “create case” action, a Flow, or middleware) and check its auth + API version — that’s the component to focus on.

Where this leaves things The timing makes the Summer ’26 release a sensible first place to look, and the “email works, Messenger doesn’t” split points at the integration’s auth or record-create permissions — but these are leads to test, not conclusions. A reproduced Messenger escalation plus the Debug Log / Login History should show what actually failed. Sharing this with Hayley’s team and their Fin/Salesforce admins is the fastest way to get to the bottom of it together. Practically: isolate the case-creation issue first (it’s cleanly date-stamped); the Guidance / multi-knowledge-base items are probably a separate thread.

Where this came from

This started as a live question at the Fin Community Office Hours.

A recurring, free session inside the Intercom community — bring your Fin, Intercom, integration & optimization questions and we work through them together, live. If this was useful, come to the next one (and bring a harder one).

“

Thank you for all of the office hours! I have learned a ton of skills that we have been able to implement in our workspace.

TM Tyler MacDonald
Director, Technical Support & Customer Experience · Versapay

“

Just wanted to say thank you to you all as I have now built my own procedure and data connector for repair updates, something I would not have been able to do or even had the confidence to give a try without everyone’s advice here!

EM Edward Morrell
Pure Electric

Nathan Sudds

Host · Fin Community Office Hours

Fin Community Expert ↗ Intercom & Fin consultant Founder, Activelabs

Host of the Fin Community Office Hours and founder of Activelabs. Nathan helps support & CX teams get more out of Intercom and Fin — integrations, optimization, procedures, and Guidance — and turns fixes into systems teams can maintain.

Book my calendar → Work with Activelabs