#Salesforce Admin321 discussing

@Sahil Gupta

Can you please check these two settings for Brochan Pane 

Hi @Julie Maris Kemena

Yes, the Personal Best feature has been

If needed, the functionality must now be implemented as a separate, custom LWC card rather than an out-of-the-box setting.

One important nuance to add to Kundan's answer, because this trips people up on Cases specifically: 

Bounce Management (Setup > Deliverability) flags the Contact/Lead/Person Account record, not the Case. Even with it enabled you will not get a bounce badge on the Case's email message itself, and 'Return bounced emails to sender' delivers the bounce notice to the sending user's own inbox, not onto the Case timeline. It also only kicks in reliably when the recipient resolves to a Contact/Lead/Person Account email, a free-typed typo address that matches no record can bounce with nothing flagged in Salesforce at all. That is most likely why your typo case showed nothing. 

How OOO replies and bounce (NDR) messages actually behave: they are just inbound emails sent back to whatever From/Reply-To you used. If you send from the Case using your Email-to-Case routing address, those replies DO come back into Salesforce, but by default they usually create a brand-new Case rather than attaching to the original, unless threading matches them up (Lightning header-based Email-to-Case threading, or the legacy Ref ID token in the subject/body). So the first thing I would check: search for Cases created from the mailer-daemon or the recipient's mail server around that time. Your OOO and bounce messages are probably sitting there as separate cases. 

If what you actually need is a reliable per-message 'did this bounce?' status shown on the Case, native Case email sending does not expose that. For that, route sending through an external email service/relay that reports bounces via webhook (e.g. SendGrid, or Email Relay with a mail server that returns delivery status), or use Marketing Cloud / Account Engagement for tracked sends. Those give true delivered/bounced status per message. 

Quick checklist: 

1. Setup > Deliverability: Bounce Management ON (flags Contact/Lead recipients). 

2. Confirm you are sending with the Email-to-Case routing address as From/Reply-To so replies return to Salesforce. 

3. Verify Email-to-Case threading (Lightning threading or Ref ID) so OOO/bounce replies attach to the original Case instead of spawning new ones. 

4. For guaranteed per-message bounce status, use an external relay with bounce webhooks or MC/Account Engagement. 

If this helps, please mark it as the Best Answer so it is easy for the next person to find. Thanks :)

Thanks for testing those, Souvik - since browser, My Domain, and admin are all ruled out, that error is almost certainly coming from one specific org-wide setting: 'Require Proof Key for Code Exchange (PKCE) Extension for Supported Authorization Flows' in Setup > OAuth and OpenID Connect Settings. 

Here's the trap: you mentioned enabling PKCE there. When that org-wide toggle is on, the org forces a code_challenge on every supported authorization flow - but the internal namespace-linking flow doesn't send one, so it fails with exactly 'missing required code_challenge'. So that setting being enabled is what's breaking the link, not something you're missing. 

The fix: turn that setting off (Setup > OAuth and OpenID Connect Settings) in the org that owns the namespace - and in the Dev Hub too if it's enabled there - then retry the namespace link. Once it's linked, you can switch it back on if you want PKCE enforced for your own apps. Note this org-wide toggle is separate from the greyed-out PKCE box on the Salesforce-managed connected app you can't edit - this one you do control. 

If it's already off and still fails, then it's on Salesforce's side (the managed linking app), and the right path is a Partner Support case referencing the error - it's a managed flow you can't patch yourself. But I'd bet on the org-wide setting; toggle it off and the link should go through. 

Hope that finally clears it! 

And if this resolves it, please mark it as the Best Answer so it helps the next person who hits this - thanks! 🙂

Hey A. Bilgic, 

Per Salesforce's own Get Records documentation, when you retrieve a single record, the flow stores it as a Record (single) variable, and you can reference any field on it later using dot notation (e.g., YourContactVar.Email, YourContactVar.FirstName), without copying values into separate individual variables first. 

For your "Continue with existing Contact" path specifically: 

1. After the Decision element splits into your two paths, for the "Continue as-is" path, just don't add an Update Records element at all, if you never call Update Records, the Contact record in the database is never touched 

2. For anything downstream that needs Contact details (like a Create Records for a related object, or a merge field on a confirmation screen), reference the fields directly off your original Get Records variable using dot notation, e.g., {!Get_Contact.Id}, {!Get_Contact.Email} 

3. If you need to show the existing values on a screen (read-only, just for confirmation) without letting the user edit them, use a Display Text component and merge in the fields with dot notation, rather than using editable Record Fields (which are what create the "must be saved via Update Records" pattern) 

The key distinction: adding record fields to a screen for editing requires Update Records to persist changes, but simply referencing the Record variable's fields via dot notation elsewhere in the flow (Create Records, Decision conditions, Display Text, etc.) never touches the database, it's purely in-memory for the duration of the flow run. 

So the short answer: keep using the single Get_Contact record variable you already have, reference fields off it directly wherever needed downstream, and just skip Update Records entirely on the "continue as-is" branch. 

Reference: