Salesforce Administrators & Developers

Hi Trailblazers,

I am facing an inconsistency between what the Lightning App Builder shows in its mobile preview (Phone Form Factor) and what is actually rendered inside the official Salesforce Mobile App on a real iOS/Android device. I would appreciate some architectural insights to clarify this behavior.

The Scenario:

1. I am customizing an Account Record Page using the Lightning App Builder.
2. Inside a Tab component, I configured two custom tabs: Activity (placed first) and Chatter (placed second).
3. When switching the Lightning App Builder preview to "Phone", the desktop Activities (Activity Timeline) component displays the classic "Unsupported form factor: Activities supports only the desktop form factor" warning.
4. To test mobile visibility, I left that desktop component there but controlled its visibility via a component filter: Device > Form Factor Equal Phone.

The Inconsistency / Questions:

• Question 1: Preview vs. Real Device Behavior 
  In the Lightning App Builder (Phone view), the
  Activity tab is strictly displayed above the Chatter tab, respecting the structural order of the Tabs component metadata. However, on the real Salesforce Mobile App device, I only see the Chatter tab and not the Activity tab. 
• Question 2: Fallback Mechanism & Smart Rendering 
  Since the desktop
  Activities Timeline component explicitly throws an "Unsupported form factor" error for mobile, what is the exact mechanism the Salesforce Mobile App uses on a real device? Does the native app container automatically suppress/ignore unsupported desktop components even if they are forced via Device = Phone filters, or does it trigger an internal fallback to the native mobile global activity card (Recent Activity)?

I want to understand if this layout discrepancy is a known limitation of the App Builder preview simulator or if there is a specific mobile rendering logic that changes the component hierarchy on real devices and hence I can't also see the tab Activity on Salesforce app in the mobile phone.

Thanks in advance for your help! 

Hi Trailblazers, 

I am a Sys Admin, and I’m facing a very frustrating behavior in Salesforce Lightning I am not used to. 

I miss the old Salesforce Classic way where you could simply click on the Accounts tab and find the "All Accounts" list view right there in the dropdown to select it. 

Currently, in my org, when I click on the Accounts tab, "All Accounts" does not appear anywhere in the List View dropdown. The only way I can actually see all accounts is by literally typing "all accounts" in the Global Search bar. When I do that and press enter, Salesforce shows me then All Accounts as one of the list views to select. 

Why does Salesforce hide the standard "All Accounts" view from the dropdown by default in newer orgs, forcing us to use Global Search?.

Is there a hidden global setting to restore the classic behavior so "All Accounts" is natively available in the dropdown without having to build a custom list view for every single object? 

Looking forward to your insights! 

Hi Trailblazers,

I am facing a very specific behavior regarding Salesforce Duplicate Management combined with Before-Save Flows (Fast Field Updates) for cross-object matching, and I would love to get the perspective of senior architects here. 

My setup:

1. Since Salesforce native Matching Rules don't support Picklists for cross-object matching (Lead vs Contact), I implemented a standard workaround. I created a custom text field called Company_Match_Text__c on both Lead and Contact.
2. A Before-Save Flow on both objects copies the value of a standard Company_Picklist__c into this custom text field upon creation/update to act as a text-normalized bridge.
3. It uses an Exact Match criteria on Contact: 
   (Contact: Email EXACT MatchBlank = FALSE) AND (Contact: Company_Match_Text__c EXACT MatchBlank = FALSE)

4. The Duplicate Rule is set to Alert and Report on both Create and Edit.

I have been analyzing two records with the exact same Email and the exact same Company text value:

• Record A: Historical record (created months ago before this Flow/Rule deployment).
• Record B: Newly created record (created today with the Flow active).

The Strange Behavior:

• When opening the new record B, the native "Potential Duplicates" Lightning Component correctly shows: "We found 1 potential duplicate" (pointing to Record A).
• However, when opening the historical Record A, the component says: "We found no potential duplicates".

For Troubleshooting I did the following:

1. I clicked Edit on Record A, changed nothing, and clicked Save. The record saved cleanly. No duplicate pop-up modal appeared, even though B exists with identical data. (However, behind the scenes, the Before-Save Flow ran and populated the custom text field for the first time).
2. I clicked Edit on Record A again, changed the company field to a completely different value, and clicked Save. It saved without alerts (Expected behavior).
3. I clicked Edit on Record A a third time, and reverted the company back to the original value to match Record B. Upon clicking Save, the Duplicate Rule instantly triggered the yellow "Similar Records Exist" pop-up window.

Mi Before Save flow works when a Contact record is created o updated.  

To give you more context on the Flow logic, the Decision Node evaluating the change is structured as follows:

• Condition Logic: (1 OR 2) AND 3

  1. {!$Record.Id

} Is Null = True (New Record) 

  2. {!$Record.Company_Picklist__c} Is Changed = True (Field Updated) 

  3. {!$Record.Company_Picklist__c} Is Null = False (Ensures field contains data) 

Because of Condition #2 (Is Changed), when we perform a "no-change" Edit -> Save on the historical Record A, this decision path evaluates to FALSE on the client/payload trigger level. However, since the record is technically hitting the database transaction, the Before-Save Assignment element still executes downstream or forces an update, which is why the field gets populated in the database but completely bypasses the Duplicate Rule UI engine. 

Is it a known behavior that Salesforce completely skips the duplicate rule evaluation UI modal on an Edit -> Save transaction if the client-side payload detects no changes in the specific fields participating in the Matching Rule even if a Before-Save Flow alters database values during that same transaction?

Would you consider this standard behavior of the Salesforce optimization/indexing engine for duplicate management, or an edge-case bug with Before-Save updates on historical data?

Thanks in advance for your insights! 

, 

Hi Trailblazers,

I am currently evaluating the architecture for a B2B customer portal using Experience Cloud. I would like to get a clear technical understanding of how Salesforce handles duplicates during user self-registration, and whether utilizing Screen Flows or LWC is truly necessary for this specific validation.   

My questions are:   

• When enabling the native Configurable Self-Registration under the Login & Registration settings, what exactly happens behind the scenes if a potential user tries to register with an email address or any data that already exists in the system? Does Salesforce natively block the registration and throw an error message, or does it require manual implementation of Duplicate/Matching Rules? 
• Does the standard self-registration mechanism only check for existing User records (login credentials), or does it also prevent creating duplicate Contact records if the email already exists in the CRM as a prospect or sales contact?
• Would you suggest using a custom Screen Flow on the public site to handle the registration intake and manually query for duplicates?. From a security and architecture perspective (especially running under the Guest User context), is a Flow recommended for this? Or is it better to stick to the native self-registration backend, perhaps customizing only the UI layer via a Lightning Web Component (LWC)?

I want to avoid reinventing the wheel if Salesforce already handles these validations natively, but I also need to ensure a clean user experience (UX) without data duplication. 

Looking forward to your architectural insights and best practices!

Thanks in advance!    @Salesforce Administrators & Developers, @Salesforce Administrators and Developers, @APAC Architects    

Hi everyone,

 I need some architectural advice regarding Email Threading for following scenario:

• When a Case is created, a Lightning Email Template is sent via Flow.
• The business wants a 'mailto' hyperlink in the email body so the customer can click it to send a follow-up email.
• This mailto link is configured to pre-fill the recipient (support@company.com) and the Subject line with the Case Number (e.g., Re: Case 00123456).

The Problem:  My assumption is that if a customer uses this mailto link, it creates a brand new email in their client (Outlook/Gmail). Since this new email lacks the original Message-ID headers (In-Reply-To / References) and the Thread ID (if using the old string-based threading), Salesforce will not be able to associate this incoming email with the existing Case, resulting in a duplicate Case.

My Questions:

1. Is my assumption correct that a standard mailto link breaks the threading logic in Salesforce Service Cloud?
2. Is there any declarative way (Flow/Standard Config) to ensure these replies attach to the original Case based solely on the Subject line containing the Case Number?
3. Or does this require Custom Development (e.g., an Apex Inbound Email Handler) to manually parse the Subject and link the email to the correct Case?

The sent of such emails should be considered for the channels email-to-case, manual and portal.

Thanks in advance for your help!    @Salesforce Administrators & Developers @Salesforce Administrators and Developers  @* Outlook/Teams, Gmail, and Inbox * @* Service Cloud *