DEV Community: Selavina B

Difficulty Debugging Black-Box Model Decisions (Salesforce Einstein / AI)

Selavina B — Tue, 13 Jan 2026 12:09:42 +0000

Why This Problem Happens (Root Causes)
You face this issue because:

Einstein Prediction Builder hides internal model logic
Limited access to:
- Feature weights
- SHAP / LIME values
Stakeholders ask “Why did this prediction happen?”
Wrong predictions are hard to debug
Trust in AI decreases

Step 1: Identify Which Einstein Tool You Are Using

Different tools = different explainability depth.

Einstein Tool Explainability Level
Prediction Builder Low (Top factors only)
Einstein Discovery Medium–High (Feature contributions)
Einstein GPT / External ML Depends on implementation
Custom ML via API Full control

If explainability is critical → Einstein Discovery or Custom ML

Step 2: Use Einstein Discovery (Built-In Explainability)
Why Einstein Discovery?
It is the only Einstein product with true model explanations.

What You Get:

Top predictors
Prediction contributions
Outcome explanations per record

Enable Explanations (UI Steps)

Go to Einstein Discovery
Open your model
Enable: Prediction Explanations Top Factors
Deploy to Salesforce Object

Example: Viewing Explanation on a Record
On an Opportunity record:

Prediction: Close Probability = 82%

Top Contributing Factors:
+ Amount > $50,000 (+18%)
+ Industry = Finance (+12%)
- Stage Duration > 60 days (-9%)

This builds stakeholder trust immediately

*Step 3: Store Einstein Explanations for Debugging (Best Practice)
*
Einstein explanations disappear unless you persist them.

Create Custom Fields
AI_Prediction__c AI_Top_Factors__c (Long Text) AI_Confidence_Score__c

Apex Example: Capture Einstein Prediction

public class EinsteinPredictionHandler {

    public static void savePrediction(
        Id recordId,
        Decimal score,
        String explanation
    ) {
        Opportunity opp = new Opportunity(
            Id = recordId,
            AI_Prediction__c = score,
            AI_Top_Factors__c = explanation
        );
        update opp;
    }
}

✔ Enables:

Auditing
Historical debugging
AI drift detection

Step 4: Detect Wrong Predictions Systematically
Add Feedback Loop (Critical Step)

Create a field:
AI_Feedback__c (Correct / Incorrect)

Apex Trigger to Log Wrong Predictions

trigger AIFeedbackTrigger on Opportunity (after update) {
    for (Opportunity opp : Trigger.new) {
        Opportunity oldOpp = Trigger.oldMap.get(opp.Id);

        if (opp.AI_Feedback__c == 'Incorrect'
            && oldOpp.AI_Feedback__c != 'Incorrect') {

            System.debug(
                'Wrong AI prediction for record: ' + opp.Id
            );
        }
    }
}

Now you have real data to retrain models

Step 5: Use Feature Contribution Analysis (Manual Debugging)

When predictions look wrong, ask:

Question Check
Wrong input data? Field completeness
Bias? Industry / Region
Stale data? Data freshness
Leakage? Outcome-related fields

Example: Detect Data Leakage
Bad Feature:
Closed_Date__c used to predict Close_Won

✔ Remove it from training dataset.

Step 6: Advanced Explainability Using SHAP (Custom AI)

If Einstein explanations are not enough, use external ML with SHAP.

Architecture
Salesforce → REST API → Python ML → SHAP → Back to Salesforce

Python Example: SHAP Explainability
import shap
import xgboost as xgb

model = xgb.XGBClassifier()
model.load_model("model.json")

explainer = shap.TreeExplainer(model)
shap_values = explainer.shap_values(X_test)

shap.summary_plot(shap_values, X_test)

Output:

Feature importance per prediction
Clear reason why model predicted something

Step 7: Push SHAP Results Back to Salesforce
Salesforce REST API (Python)

import requests

payload = {
    "AI_Explanation__c": "High Amount (+0.21), Industry Finance (+0.15)"
}

requests.patch(
    "https://yourInstance.salesforce.com/services/data/v59.0/sobjects/Opportunity/006XXXX",
    headers=headers,
    json=payload
)

✔ Salesforce becomes AI-transparent

Step 8: Add Guardrails for AI Trust
Best Practices Checklist

✔ Never deploy AI without explanations
✔ Log predictions + explanations
✔ Allow user feedback
✔ Monitor prediction drift
✔ Retrain quarterly

Step 9: Communicate AI Decisions to Stakeholders
Human-Readable Explanation Format

Bad:
Model Score: 0.82

Good:

This opportunity has a high chance to close because:
• Deal size is above average
• Customer is in a high-conversion industry
• Sales cycle duration is within healthy range

Step 10: When NOT to Use Einstein

Avoid Einstein when:

Legal compliance requires explainability
Decisions affect credit, pricing, or risk
Stakeholders demand transparency Use custom ML + SHAP instead

🔍 Faster debugging
🧠 Higher trust in AI
📊 Better retraining signals
⚖ Compliance-ready AI
salesforce development company

Trigger Logic Causing Recursive Updates or Data Duplication

Selavina B — Thu, 08 Jan 2026 12:40:42 +0000

Problem Statement: Poorly designed Apex triggers run multiple times per transaction, causing recursive updates, duplicate records, or unintended field changes due to missing recursion guards, mixed responsibilities, or lack of a trigger framework.

Salesforce Trigger Logic Causing Recursive Updates or Data Duplication
Step-by-Step Fix (with Code)
Why This Happens in Salesforce
Salesforce triggers can run multiple times in a single transaction:

before insert
after insert
before update
after update

Recursion and duplication occur when:

A trigger updates the same object it fires on
Multiple triggers handle the same logic
No recursion guard is used
Logic is scattered across trigger contexts

Common Symptoms

Duplicate child records created
Fields updated repeatedly
CPU time limit exceeded
“Too many DML statements” errors
Records updated even when values didn’t change

Step 1 Identify the BAD trigger pattern
WRONG: Updating records inside after update without guard

trigger AccountTrigger on Account (after update) {
    for (Account acc : Trigger.new) {
        acc.Description = 'Updated';
    }
    update Trigger.new; //  Recursive trigger
}

This re-fires the trigger endlessly.

Step 2 Move logic to a Trigger Handler Framework
Trigger (Single Responsibility)

trigger AccountTrigger on Account (
    before insert, before update,
    after insert, after update
) {
    AccountTriggerHandler.run(
        Trigger.operationType,
        Trigger.new,
        Trigger.oldMap
    );
}

One trigger per object
No logic inside trigger

Step 3 Add a Recursion Guard (Critical)
Static Boolean Guard

public class TriggerControl {
    public static Boolean isRunning = false;
}

Step 4 Implement Guarded Logic in Handler

public class AccountTriggerHandler {

    public static void run(
        System.TriggerOperation operation,
        List<Account> newList,
        Map<Id, Account> oldMap
    ) {
        if (TriggerControl.isRunning) return;
        TriggerControl.isRunning = true;

        if (operation == System.TriggerOperation.BEFORE_UPDATE) {
            beforeUpdate(newList, oldMap);
        }

        if (operation == System.TriggerOperation.AFTER_INSERT) {
            afterInsert(newList);
        }

        TriggerControl.isRunning = false;
    }
}

Prevents recursive execution
Centralized control

Step 5 Only Update Records When Data Actually Changes
BAD

acc.Status__c = 'Active';

Runs every time → recursion.

GOOD

if (acc.Status__c != 'Active') {
    acc.Status__c = 'Active';
}

Prevents unnecessary updates
Reduces trigger re-fires

Step 6 Never Insert Child Records Without Duplication Checks
BAD (duplicates)

insert new Contact(
    LastName = 'Auto',
    AccountId = acc.Id
);

GOOD (check existing records)

Map<Id, Integer> contactCountMap = new Map<Id, Integer>();

for (AggregateResult ar : [
    SELECT AccountId accId, COUNT(Id) cnt
    FROM Contact
    WHERE AccountId IN :accountIds
    GROUP BY AccountId
]) {
    contactCountMap.put((Id) ar.get('accId'), (Integer) ar.get('cnt'));
}

List<Contact> contactsToInsert = new List<Contact>();
for (Account acc : newList) {
    if (!contactCountMap.containsKey(acc.Id)) {
        contactsToInsert.add(
            new Contact(LastName = 'Auto', AccountId = acc.Id)
        );
    }
}
insert contactsToInsert;

No duplicates
Bulk-safe

Step 7 Use before Triggers Instead of after When Possible
BAD

after update → update same record

GOOD

before update → modify Trigger.new

if (acc.Score__c == null) {
    acc.Score__c = 0;
}

No DML
No recursion

Step 8 Split Logic by Responsibility
BAD

Validation
Field updates
Record creation
Callouts All in one trigger.

GOOD Architecture

AccountTriggerHandler
AccountService
AccountValidator
AccountAsyncProcessor
Easier testing
No duplicate execution

Step 9 Prevent Cross-Object Trigger Loops
COMMON LOOP

Account trigger updates Contact
Contact trigger updates Account
FIX Shared Static Guard

public class GlobalTriggerState {
    public static Set<String> executed = new Set<String>();
}

if (GlobalTriggerState.executed.contains('Account')) return;
GlobalTriggerState.executed.add('Account');

Prevents infinite cross-object loops

Step 10 Final Safe Trigger Template (Production-Ready)

trigger AccountTrigger on Account (before update, after insert) {
    if (TriggerControl.isRunning) return;
    TriggerControl.isRunning = true;

    if (Trigger.isBefore && Trigger.isUpdate) {
        for (Account acc : Trigger.new) {
            if (acc.Status__c != 'Active') {
                acc.Status__c = 'Active';
            }
        }
    }

    if (Trigger.isAfter && Trigger.isInsert) {
        AccountService.createDefaultContacts(Trigger.new);
    }

    TriggerControl.isRunning = false;
}

Conclusion
In Salesforce Development, recursive triggers and data duplication are not platform bugs they are design issues. The fix is disciplined trigger architecture: one trigger per object, handler classes, recursion guards, before-trigger updates, and strict duplication checks. When triggers are treated as event routers instead of logic containers, recursion stops, data stays clean, and your org becomes stable and scalable.

Performance Degradation Due to Inefficient Apex / ORM Usage (salesforce)

Selavina B — Wed, 07 Jan 2026 09:31:54 +0000

Problem Statement: Slow page loads, long batch jobs, or timeouts occur when Apex code is not bulk-safe, triggers perform row-by-row operations, or inefficient queries are used, leading to governor limit exceptions and poor org performance.

Step 1 Identify Inefficient Apex Patterns
Common Bad Practice

trigger AccountTrigger on Account (after insert, after update) {
    for (Account acc : Trigger.new) {
        // N+1 query inside loop
        List<Contact> contacts = [SELECT Id, Email FROM Contact WHERE AccountId = :acc.Id];
        for (Contact c : contacts) {
            c.Email = acc.Name + '.contact@example.com';
            update c; // DML inside loop
        }
    }
}

Problems:

SOQL in a loop → N+1 problem
DML in a loop → governor limit errors
Not bulk-safe → fails on large record batches

Step 2 Make Apex Code Bulk-Safe
Rule: Always process collections (lists, maps, sets) and avoid per-record queries or DML inside loops.

Bulk-Safe Version

trigger AccountTrigger on Account (after insert, after update) {
    // Step 1: Collect all Account IDs
    Set<Id> accountIds = new Set<Id>();
    for (Account acc : Trigger.new) {
        accountIds.add(acc.Id);
    }

    // Step 2: Query all related contacts at once
    List<Contact> contactsToUpdate = [
        SELECT Id, Email, AccountId 
        FROM Contact 
        WHERE AccountId IN :accountIds
    ];

    // Step 3: Prepare contacts for update
    for (Contact c : contactsToUpdate) {
        Account parent = Trigger.newMap.get(c.AccountId);
        c.Email = parent.Name + '.contact@example.com';
    }

    // Step 4: Bulk DML
    if (!contactsToUpdate.isEmpty()) {
        update contactsToUpdate;
    }
}

Benefits:

Single SOQL query → avoids N+1 problem
Single DML statement → governor-safe
Works with hundreds or thousands of records

Step 3 Optimize SOQL Queries

Use relationship queries when possible

List<Account> accounts = [
    SELECT Id, Name, (SELECT Id, Email FROM Contacts) 
    FROM Account
    WHERE Industry = 'Technology'
];

Avoid unnecessary fields: SELECT Id, Name instead of SELECT *
Filter records using WHERE and LIMIT to reduce data size

Step 4 Use Maps for Fast Lookups
Instead of iterating nested loops, use maps to improve performance:

Map<Id, Account> accountMap = new Map<Id, Account>(Trigger.new);

for (Contact c : contactsToUpdate) {
    Account parent = accountMap.get(c.AccountId);
    c.Email = parent.Name + '.contact@example.com';
}

Lookup in O(1) instead of O(n²)

Step 5 Move Logic to Handler Classes

Trigger:

trigger AccountTrigger on Account (after insert, after update) {
    AccountTriggerHandler.handleAfter(Trigger.new, Trigger.oldMap);
}

Handler Class:

public class AccountTriggerHandler {
    public static void handleAfter(List<Account> newList, Map<Id, Account> oldMap) {
        Set<Id> accIds = new Set<Id>();
        for (Account acc : newList) accIds.add(acc.Id);

        List<Contact> contacts = [SELECT Id, AccountId FROM Contact WHERE AccountId IN :accIds];
        Map<Id, Account> accountMap = new Map<Id, Account>(newList);

        for (Contact c : contacts) {
            c.Email = accountMap.get(c.AccountId).Name + '.contact@example.com';
        }

        if (!contacts.isEmpty()) update contacts;
    }
}

Benefits:

Cleaner code
Easier debugging
Easy to reuse in batch jobs

Step 6 — Use Batch Apex for Large Data Volumes

For large record sets, Batch Apex is essential:

global class UpdateContactsBatch implements Database.Batchable<SObject> {
    global Database.QueryLocator start(Database.BatchableContext BC) {
        return Database.getQueryLocator([SELECT Id, AccountId FROM Contact]);
    }

    global void execute(Database.BatchableContext BC, List<Contact> scope) {
        Set<Id> accountIds = new Set<Id>();
        for (Contact c : scope) accountIds.add(c.AccountId);

        Map<Id, Account> accMap = new Map<Id, Account>([
            SELECT Id, Name FROM Account WHERE Id IN :accountIds
        ]);

        for (Contact c : scope) {
            c.Email = accMap.get(c.AccountId).Name + '.contact@example.com';
        }

        update scope;
    }

    global void finish(Database.BatchableContext BC) {}
}

Processes 50k+ records safely
Avoids governor limits
Bulk-safe architecture

Step 7 Use @future or Queueable for Non-Critical Operations

For operations not required immediately (like sending emails or updating related objects):

@future

public static void updateContactEmails(Set accountIds) {
List contacts = [SELECT Id, AccountId FROM Contact WHERE AccountId IN :accountIds];
for (Contact c : contacts) {
c.Email = [SELECT Name FROM Account WHERE Id = :c.AccountId].Name + '.contact@example.com';
}
update contacts;
}

Moves heavy work out of synchronous transaction
Reduces UI latency

Step 8 Monitor and Test

Enable Debug Logs → check SOQL and DML statements
Test with bulk records (200+)
Use Query Plan Tool for expensive queries

Conclusion

Performance degradation in Salesforce is almost always caused by inefficient Apex code or improper ORM usage. By making triggers bulk-safe, using batch operations, minimizing SOQL/DML inside loops, and separating logic into handler classes or batch jobs, you can eliminate slow page loads, prevent governor limit errors, and scale your org for large datasets efficiently.

Salesforce Apex Code Failing Due to Lack of Bulkification

Selavina B — Tue, 30 Dec 2025 12:23:58 +0000

Salesforce Apex Code Failing Due to Lack of Bulkification (And How to Fix It)

If you are developing on Salesforce, sooner or later you will face this error:

Too many SOQL queries: 101
Too many DML statements
CPU time limit exceeded

In most cases, the root cause is simple but dangerous:
your Apex code is not bulkified.

This issue usually does not appear during development or testing with single records. It shows up suddenly in production during data imports, integrations, or batch jobs and breaks business processes.

This post explains what bulkification really means, why Apex fails without it, and how to fix it properly with code.

The Real Problem
Salesforce does not execute Apex code one record at a time.

Instead:

Triggers can receive up to 200 records
Batch Apex can process thousands
Data Loader and integrations insert records in bulk

If your Apex logic assumes single-record execution, Salesforce governor limits will be exceeded.

That’s when things fail.

Step 1: Understand How Salesforce Executes Apex
Consider this trigger:

trigger AccountTrigger on Account (before insert) {
    for (Account acc : Trigger.new) {
        // Your logic here
    }
}

This trigger might:

Run for 1 record
Or 200 records at once

Salesforce does not guarantee single-record execution.
Your code must always expect bulk input.

Step 2: Identify Non-Bulkified Code

Non-bulkified Apex

trigger ContactTrigger on Contact (after insert) {
    for (Contact c : Trigger.new) {
        Account acc = [
            SELECT Id, Name
            FROM Account
            WHERE Id = :c.AccountId
        ];

        acc.Description = 'Updated';
        update acc;
    }
}

Why this fails

One SOQL query per record
One DML per record
200 records = 200 queries + 200 DML
Governor limits exceeded

This code will break in production.

Step 3: Bulkify SOQL Queries (The Right Way)

Correct bulkified approach

trigger ContactTrigger on Contact (after insert) {

    Set<Id> accountIds = new Set<Id>();

    for (Contact c : Trigger.new) {
        if (c.AccountId != null) {
            accountIds.add(c.AccountId);
        }
    }

    Map<Id, Account> accountMap = new Map<Id, Account>(
        [SELECT Id, Description FROM Account WHERE Id IN :accountIds]
    );

    for (Account acc : accountMap.values()) {
        acc.Description = 'Updated';
    }

    update accountMap.values();
}

What changed

One SOQL query
One DML statement
Works for 1 record or 200 records
Safe for production

Step 4: Never Put SOQL or DML Inside Loops

This is the golden rule of Apex.

What NOT to do

for (Opportunity opp : Trigger.new) {
    insert new Task(WhatId = opp.Id);
}

Correct approach

List<Task> tasks = new List<Task>();

for (Opportunity opp : Trigger.new) {
    tasks.add(new Task(WhatId = opp.Id));
}

insert tasks;

Step 5: Bulkify Helper Classes and Services

Bulkification must apply everywhere, not just triggers.

Hidden problem

public class AccountService {
    public static void updateAccount(Id accId) {
        Account acc = [SELECT Id FROM Account WHERE Id = :accId];
        acc.Name = 'Updated';
        update acc;
    }
}

Calling this method in a loop will break limits.

Bulk-safe service method

public class AccountService {
    public static void updateAccounts(Set<Id> accountIds) {

        List<Account> accounts = [
            SELECT Id, Name FROM Account WHERE Id IN :accountIds
        ];

        for (Account acc : accounts) {
            acc.Name = 'Updated';
        }

        update accounts;
    }
}

Step 6: Use Trigger Handler Pattern (Highly Recommended)

Multiple triggers increase risk of non-bulkified logic.

Trigger

trigger AccountTrigger on Account (before update) {
    AccountHandler.beforeUpdate(Trigger.new);
}

Handler

public class AccountHandler {
    public static void beforeUpdate(List<Account> accounts) {
        for (Account acc : accounts) {
            // Bulk-safe logic
        }
    }
}

This pattern:

Forces bulk handling
Improves readability
Simplifies testing

Step 7: Write Bulk Test Cases (Mandatory)

If your test inserts only one record, your code is not truly tested.

Weak test

insert new Account(Name = 'Test');

Proper bulk test

List<Account> accounts = new List<Account>();

for (Integer i = 0; i < 200; i++) {
    accounts.add(new Account(Name = 'Test ' + i));
}

insert accounts;

If this test fails → your code is not bulkified.

Step 8: Watch These Governor Limits Closely

Limit	Max
SOQL queries	100
DML statements	150
Records per DML	10,000
CPU time	10 sec (sync)

Bulkification is the only way to stay within these limits.

Key Takeaways

Salesforce Apex code usually fails in production not because it is wrong—but because it is written for single records.

To avoid failures:

Assume every trigger runs on 200 records
Never put SOQL or DML inside loops
Use collections (Set, Map, List)
Bulkify service classes
Test with bulk data, not single records

Once you adopt bulk-first thinking, Apex becomes stable, scalable, and production-safe.

Salesforce integration failures with external systems

Selavina B — Mon, 29 Dec 2025 12:32:07 +0000

Salesforce Integration Failures: How I Debugged and Fixed API Callout Issues in Production
Salesforce integrations look simple on paper.
Make a REST call. Send data. Get a response.

In reality, Salesforce integrations fail in silent, unpredictable ways, especially in production:

Data sync stops without warning
Callouts fail intermittently
Authentication suddenly breaks
Jobs keep retrying but never succeed I recently faced this issue in a live Salesforce org, and the root cause was not one thing—it was a combination of bad assumptions, missing error handling, and weak observability.

This post explains why Salesforce integrations fail, and how to fix them properly, step by step.

The Core Problem
Salesforce integrations with external systems fail mainly because:

Callout errors are not logged properly
Authentication tokens expire silently
Timeout and retry logic is missing
Errors happen inside async jobs (Batch, Queueable, Future)
Developers assume APIs behave consistently

Salesforce does not automatically “protect” your integration.
If you don’t handle failures explicitly, they go unnoticed.

Step 1: Confirm the Integration Entry Point
First, identify where the integration is running:

Trigger-based callout?
Queueable Apex?
Batch Apex?
Scheduled job?

Most failures happen inside asynchronous Apex, not UI-triggered flows.

Example (Queueable integration):

System.enqueueJob(new SyncOrderJob(orderId));
If this job fails, the UI will never show an error.

Step 2: Never Call External APIs Directly From Triggers
This is a very common Salesforce mistake.
Wrong approach

trigger OrderTrigger on Order__c (after insert) {
    HttpRequest req = new HttpRequest();
    // Callout directly from trigger
}

This causes:

Callout exceptions
Governor limit issues
Unpredictable failures

Correct architecture
Trigger → Queueable → Callout

trigger OrderTrigger on Order__c (after insert) {
    System.enqueueJob(new SyncOrderJob(Trigger.new));
}

Step 3: Use Named Credentials (Non-Negotiable)
Hardcoding endpoints or tokens will break in production.
Bad practice

req.setEndpoint('https://api.partner.com/v1/orders');
req.setHeader('Authorization', 'Bearer hardcoded_token');

Correct approach (Named Credential)

Go to Setup → Named Credentials
Configure:
- Base URL
- Authentication (OAuth 2.0 / JWT / API Key)
Use it in Apex
req.setEndpoint('callout:Partner_API/orders');
Benefits:

Automatic token refresh
Environment-safe
More secure

Step 4: Always Wrap Callouts in try–catch
This is the main reason Salesforce integrations fail silently.

Common mistake

HttpResponse res = http.send(req);
System.debug(res.getBody());

If it fails → job dies → no visibility.

Production-safe code

try {
    Http http = new Http();
    HttpResponse res = http.send(req);

    if (res.getStatusCode() != 200) {
        throw new CalloutException(
            'API Error: ' + res.getStatus() + ' - ' + res.getBody()
        );
    }

} catch (Exception e) {
    System.debug('Integration failed: ' + e.getMessage());
}

Step 5: Log Failures (Do Not Rely on Debug Logs)
Debug logs are temporary and unreliable in production.

Create a custom Integration_Log__c object.

public static void logError(String source, String message) {
    Integration_Log__c log = new Integration_Log__c(
        Source__c = source,
        Error_Message__c = message
    );
    insert log;
}

Use it in catch blocks:

catch (Exception e) {
    logError('Order Sync', e.getMessage());
}

Now failures are:

Persistent
Reportable
Auditable

Step 6: Handle Timeouts Explicitly
Salesforce has strict timeout limits.
req.setTimeout(10000); // 10 seconds
If your external API is slow and you don’t set this:

Salesforce terminates the request
No clear error is shown

Step 7: Use Queueable Apex for Retries
Salesforce does not auto-retry failed callouts.

Add retry logic manually.

if (retryCount < 3) {
    System.enqueueJob(new SyncOrderJob(orderId, retryCount + 1));
}

This alone fixes many “random” integration failures.

Step 8: Check Remote Site Settings (Classic Issue)
If you are not using Named Credentials, your callout will fail silently.

Go to:
Setup → Remote Site Settings
https://api.partner.com
Missing this = guaranteed failure.

Step 9: Test Callouts Properly (Mocking Required)
Salesforce will not allow real callouts in tests.

@isTest
private class OrderSyncTest {
    static testMethod void testCallout() {
        Test.setMock(HttpCalloutMock.class, new MockResponse());
        Test.startTest();
        System.enqueueJob(new SyncOrderJob(orderId));
        Test.stopTest();
    }
}

Without mocks:

Tests fail
Deployment blocked

Step 10: Monitor Async Jobs Regularly

Go to:
Setup → Apex Jobs

Look for:

Failed Queueables
Aborted Batch jobs
Long-running executions Most integration failures show up here first.

Key Takeaways
Salesforce integrations don’t fail because Salesforce is weak.
They fail because developers trust external systems too much.

To make integrations production-safe:

Always use Named Credentials
Never call APIs from triggers
Log every failure
Handle retries explicitly
Treat async jobs as first-class systems

Once these practices are in place, Salesforce integrations become stable, observable, and predictable.

Trigger Logic Causing Recursive Updates or Data Duplication (Salesforce)

Selavina B — Tue, 23 Dec 2025 05:25:57 +0000

Problem statement
Poorly designed Apex triggers run multiple times per transaction, causing recursive updates, duplicate records, or unintended field changes because of missing recursion guards, mixed responsibilities, or lack of a trigger framework.

Step 1 Understand WHY recursion happens

Triggers can fire multiple times in a single transaction:

before insert
after insert
before update
after update

Common causes of recursion

Trigger updates the same object again
Trigger updates a related object that triggers back
Workflow / Flow / Process Builder updates fields → re-fires trigger
No guard to stop re-execution

Example of bad trigger logic

trigger AccountTrigger on Account (after update) {
    for (Account acc : Trigger.new) {
        acc.Description = 'Updated'; // causes recursion
    }
    update Trigger.new;
}

This will loop until governor limits are hit.

Step 2 Use ONE trigger per object (no logic inside)
Correct trigger structure

Triggers should only:

Detect context
Call a handler

trigger AccountTrigger on Account (
    before insert, before update,
    after insert, after update
) {
    AccountTriggerHandler.run(
        Trigger.new,
        Trigger.oldMap,
        Trigger.isInsert,
        Trigger.isUpdate,
        Trigger.isBefore,
        Trigger.isAfter
    );
}

No logic. No loops. No DML here.

Step 3 Add a recursion guard (MANDATORY)
Static Boolean Guard Pattern (most reliable)

public class TriggerGuard {
    private static Set<String> executed = new Set<String>();

    public static Boolean shouldRun(String key) {
        if (executed.contains(key)) {
            return false;
        }
        executed.add(key);
        return true;
    }
}

This guard works per transaction.

Step 4 Implement a proper Trigger Handler

public with sharing class AccountTriggerHandler {

    public static void run(
        List<Account> newList,
        Map<Id, Account> oldMap,
        Boolean isInsert,
        Boolean isUpdate,
        Boolean isBefore,
        Boolean isAfter
    ) {
        if (isBefore && isInsert) {
            beforeInsert(newList);
        }
        if (isBefore && isUpdate) {
            beforeUpdate(newList, oldMap);
        }
        if (isAfter && isInsert) {
            afterInsert(newList);
        }
        if (isAfter && isUpdate) {
            afterUpdate(newList, oldMap);
        }
    }

    // ------------------ BEFORE INSERT ------------------
    private static void beforeInsert(List<Account> records) {
        for (Account acc : records) {
            if (acc.Description == null) {
                acc.Description = 'Created';
            }
        }
    }

    // ------------------ BEFORE UPDATE ------------------
    private static void beforeUpdate(List<Account> records, Map<Id, Account> oldMap) {
        for (Account acc : records) {
            Account oldAcc = oldMap.get(acc.Id);
            if (acc.Name != oldAcc.Name) {
                acc.Description = 'Name Changed';
            }
        }
    }

    // ------------------ AFTER INSERT ------------------
    private static void afterInsert(List<Account> records) {
        if (!TriggerGuard.shouldRun('AccountAfterInsert')) return;

        List<Contact> contacts = new List<Contact>();
        for (Account acc : records) {
            contacts.add(new Contact(
                LastName = 'Primary',
                AccountId = acc.Id
            ));
        }
        insert contacts; // safe
    }

    // ------------------ AFTER UPDATE ------------------
    private static void afterUpdate(List<Account> records, Map<Id, Account> oldMap) {
        if (!TriggerGuard.shouldRun('AccountAfterUpdate')) return;

        List<Account> toUpdate = new List<Account>();
        for (Account acc : records) {
            Account oldAcc = oldMap.get(acc.Id);

            // Only update if field actually changed
            if (acc.AnnualRevenue != oldAcc.AnnualRevenue) {
                toUpdate.add(new Account(
                    Id = acc.Id,
                    Rating = 'Hot'
                ));
            }
        }

        if (!toUpdate.isEmpty()) {
            update toUpdate; // guarded → no recursion
        }
    }
}

Step 5 Prevent duplicate records (idempotency check)
Bad (creates duplicates)
insert new Contact(AccountId = acc.Id, LastName = 'Primary');

Good (check before insert)

Set<Id> accountIds = new Set<Id>();
for (Account acc : records) {
    accountIds.add(acc.Id);
}

Map<Id, Contact> existing = new Map<Id, Contact>();
for (Contact c : [
    SELECT Id, AccountId
    FROM Contact
    WHERE AccountId IN :accountIds
    AND LastName = 'Primary'
]) {
    existing.put(c.AccountId, c);
}

List<Contact> toInsert = new List<Contact>();
for (Account acc : records) {
    if (!existing.containsKey(acc.Id)) {
        toInsert.add(new Contact(
            LastName = 'Primary',
            AccountId = acc.Id
        ));
    }
}

insert toInsert;

Step 6 Never do DML in BEFORE triggers (rule)

Context Allowed
before insert/update DML
after insert/update DML
before modify Trigger.new
after separate update list

Step 7 Handle Flow / Process Builder recursion

Flows often cause recursion without you realizing it.

Safe pattern:

Triggers handle core data logic

Flows handle UI / notifications

Detection:

If recursion still occurs:

Check Record-Triggered Flows
Ensure Flow entry criteria prevents re-firing

Example Flow criteria:

Run only when:
AnnualRevenue IS CHANGED = TRUE

Step 8 Add tests that prove recursion is fixed

@IsTest
private class AccountTriggerTest {

    @IsTest
    static void testNoRecursion() {
        Account acc = new Account(Name = 'Test');
        insert acc;

        Test.startTest();
        acc.AnnualRevenue = 500000;
        update acc;
        Test.stopTest();

        Account updated = [
            SELECT Rating, Description
            FROM Account
            WHERE Id = :acc.Id
        ];

        System.assertEquals('Hot', updated.Rating);
        System.assertNotEquals(null, updated.Description);
    }
}

If recursion exists, this test will fail or hit limits.

Step 9 Golden rules to prevent recursion forever

One trigger per object
Zero business logic in triggers
Use handler classes
Always compare Trigger.new vs Trigger.old
Never update records blindly
Use static guards for after triggers
Bulk-safe logic only

Conclusion

Trigger recursion and data duplication happen when Apex triggers lack clear separation of responsibilities, field-change checks, and recursion guards. By adopting a single-trigger + handler framework, using static execution guards, performing bulk-safe DML, and ensuring updates happen only when data truly changes, you can completely eliminate infinite loops, duplicate records, and unpredictable behavior. Well structured triggers are not just safer they’re easier to test, scale, and maintain in production.

Integration Failures and API Callout Issues in Salesforce

Selavina B — Tue, 16 Dec 2025 10:39:55 +0000

Problem statement:
External integrations (REST/SOAP) intermittently fail due to unhandled callout errors, timeout issues, changes in external API contracts, or missing named credentials, causing data sync problems between Salesforce and external systems.

Step 1 Fix the #1 root cause: Authentication + Endpoint setup
Use Named Credentials (don’t hardcode URL/tokens)

Setup → Named Credentials

Create External Credential + Named Credential (newer setup) OR classic Named Credential.
Ensure:
Correct base URL (prod vs sandbox)
Auth method (OAuth 2.0 / JWT / Basic)
Proper scopes/permissions
Add required Headers if the API needs them (e.g., API key header)

Why: Missing/incorrect Named Credentials causes intermittent 401/403 and “it works sometimes” issues due to token refresh failures.

Step 2 Create a single, reusable Apex callout wrapper (handles errors properly)
Apex: Callout service with status-code handling + timeout + safe parsing

public with sharing class ExternalApiService {
    public class ApiException extends Exception {
        public Integer statusCode;
        public String responseBody;
        public ApiException(String msg, Integer code, String body) {
            super(msg);
            statusCode = code;
            responseBody = body;
        }
    }

    public class ApiResponse {
        @AuraEnabled public Integer statusCode;
        @AuraEnabled public String body;
        @AuraEnabled public Map<String, Object> json; // tolerant parsing
    }

    // Named Credential: "Order_API"
    // Endpoint usage: callout:Order_API/path
    public static ApiResponse sendRequest(String method, String path, String jsonBody, Integer timeoutMs) {
        HttpRequest req = new HttpRequest();
        req.setMethod(method);
        req.setEndpoint('callout:Order_API' + path);
        req.setTimeout(timeoutMs == null ? 20000 : timeoutMs); // default 20s

        req.setHeader('Content-Type', 'application/json');
        req.setHeader('Accept', 'application/json');

        if (!String.isBlank(jsonBody) && (method == 'POST' || method == 'PUT' || method == 'PATCH')) {
            req.setBody(jsonBody);
        }

        Http http = new Http();
        HttpResponse res;
        try {
            res = http.send(req);
        } catch (System.CalloutException ce) {
            // Timeouts, DNS, handshake, etc.
            throw new ApiException('Callout failed: ' + ce.getMessage(), 0, null);
        }

        ApiResponse out = new ApiResponse();
        out.statusCode = res.getStatusCode();
        out.body = res.getBody();

        // Handle common failure codes clearly
        if (out.statusCode >= 400) {
            throw new ApiException(
                'External API error. Status=' + out.statusCode,
                out.statusCode,
                out.body
            );
        }

        // Tolerant JSON parsing (prevents failures if API adds fields)
        if (!String.isBlank(out.body) && out.body.trim().startsWith('{')) {
            out.json = (Map<String, Object>) JSON.deserializeUntyped(out.body);
        }
        return out;
    }
}

What this fixes

Intermittent failures become visible and actionable (proper exceptions + status codes)

Timeouts are handled

JSON parsing is resilient to “API contract changes” (new fields won’t break your code)

Step 3 Add retries for transient failures (timeouts, 429, 5xx)

Retries should be async (Queueable) and limited.

Queueable retry worker (with simple backoff + max attempts)


public with sharing class ExternalSyncJob implements Queueable, Database.AllowsCallouts {
    private Id recordId;
    private Integer attempt;

    public ExternalSyncJob(Id recordId, Integer attempt) {
        this.recordId = recordId;
        this.attempt = attempt == null ? 1 : attempt;
    }

    public void execute(QueueableContext context) {
        // Example: sync an Order__c record
        Order__c ord = [
            SELECT Id, Name, Amount__c, External_Id__c
            FROM Order__c
            WHERE Id = :recordId
            LIMIT 1
        ];

        String payload = JSON.serialize(new Map<String, Object>{
            'orderName' => ord.Name,
            'amount' => ord.Amount__c,
            'externalId' => ord.External_Id__c
        });

        try {
            ExternalApiService.ApiResponse resp =
                ExternalApiService.sendRequest('POST', '/orders', payload, 20000);

            // Mark success
            ord.Last_Sync_Status__c = 'SUCCESS';
            ord.Last_Sync_Message__c = 'Synced OK';
            update ord;

        } catch (ExternalApiService.ApiException ex) {
            // Retry only for transient cases
            Boolean transientFail =
                ex.statusCode == 0 || ex.statusCode == 429 || (ex.statusCode >= 500 && ex.statusCode <= 599);

            logIntegration('Order Sync', recordId, 'ERROR',
                'Attempt ' + attempt + ' failed. Status=' + ex.statusCode,
                ex.responseBody
            );

            if (transientFail && attempt < 3) {
                // Re-enqueue (basic retry). For real backoff, schedule later (see note below).
                System.enqueueJob(new ExternalSyncJob(recordId, attempt + 1));
            } else {
                ord.Last_Sync_Status__c = 'FAILED';
                ord.Last_Sync_Message__c = 'Final failure: ' + ex.getMessage();
                update ord;
            }
        }
    }

    private static void logIntegration(String operation, Id relatedId, String level, String message, String body) {
        try {
            Integration_Log__c log = new Integration_Log__c(
                Operation__c = operation,
                Related_Record_Id__c = String.valueOf(relatedId),
                Level__c = level,
                Message__c = message,
                Payload__c = body
            );
            insert log;
        } catch (Exception ignore) {}
    }
}

If you want true backoff delays (e.g., wait 5 min), use Schedulable or Platform Events + subscriber. Queueable runs immediately.

Step 4 Prevent “contract change” breaks with tolerant parsing

If you currently do strict deserialization like:

MyDto dto = (MyDto) JSON.deserialize(body, MyDto.class);

This can break when:

API changes data type
Field becomes null
Response shape changes

Safer parsing pattern


Map<String, Object> m = (Map<String, Object>) JSON.deserializeUntyped(body);
Object value = m.get('status'); // check exists
String status = value == null ? null : String.valueOf(value);

You can still map to DTOs, but keep tolerant fallback for critical fields.

Step 5 Use idempotency to avoid duplicate writes (very common in retries)

When retries happen, you must ensure you don’t create duplicates externally.

Add an idempotency key header (if API supports it)
req.setHeader('Idempotency-Key', String.valueOf(recordId));

Or always send a stable externalId in payload and have the external system “upsert”.

Step 6 Add proper monitoring (so “intermittent” becomes measurable)

Create a custom object like Integration_Log__c with fields:

Operation__c
Related_Record_Id__c
Level__c (INFO/ERROR)
Message__c
Payload__c (Long Text)
Status_Code__c (Number)
Timestamp__c (Date/Time)

Then build a simple report/dashboard:

Failures by day
Top error codes (401/403/429/5xx)
Records with repeated failures

Step 7 Write stable tests using HttpCalloutMock (mandatory for deployments)
Mock success + failure


@IsTest
private class ExternalApiServiceTest {

    private class SuccessMock implements HttpCalloutMock {
        public HTTPResponse respond(HTTPRequest req) {
            HttpResponse res = new HttpResponse();
            res.setStatusCode(200);
            res.setBody('{"status":"ok","id":"ABC123"}');
            return res;
        }
    }

    private class FailureMock implements HttpCalloutMock {
        public HTTPResponse respond(HTTPRequest req) {
            HttpResponse res = new HttpResponse();
            res.setStatusCode(500);
            res.setBody('{"error":"server_error"}');
            return res;
        }
    }

    @IsTest
    static void testSendRequestSuccess() {
        Test.setMock(HttpCalloutMock.class, new SuccessMock());

        ExternalApiService.ApiResponse resp =
            ExternalApiService.sendRequest('GET', '/health', null, 5000);

        System.assertEquals(200, resp.statusCode);
        System.assertEquals('ok', String.valueOf(resp.json.get('status')));
    }

    @IsTest
    static void testSendRequestFailureThrows() {
        Test.setMock(HttpCalloutMock.class, new FailureMock());
        try {
            ExternalApiService.sendRequest('GET', '/health', null, 5000);
            System.assert(false, 'Expected exception');
        } catch (ExternalApiService.ApiException ex) {
            System.assertEquals(500, ex.statusCode);
        }
    }
}

Conclusion

Integration failures in Salesforce usually feel “intermittent” because the root causes are hidden auth/token issues, timeouts, rate limits (429), server errors (5xx), or small API contract changes. If callouts aren’t handled with proper status checks, timeouts, retries, and logging, a single external glitch can break your sync and create messy production incidents.
To make integrations stable and predictable:

Use Named Credentials so authentication and endpoints are managed securely and consistently.
Build a single callout wrapper that handles timeouts, validates HTTP status codes, and parses responses safely.
Retry only transient failures (timeouts/429/5xx) using Queueable callouts, and avoid duplicates with idempotency keys/external IDs.
Add structured logging + monitoring so failures are visible, traceable, and measurable.
Write strong HttpCalloutMock tests so deployments don’t break and issues are caught early.
With these practices, your Salesforce-to-external-system sync becomes reliable, debuggable, and production-ready, even when external APIs change or behave unpredictably.

Salesforce LWC/Aura UI Bugs and Performance Bottlenecks

Selavina B — Sat, 13 Dec 2025 12:57:04 +0000

Problem statement
Lightning components load slowly, fail with large datasets, or throw runtime errors due to inefficient Apex calls, poor state management, and missing error handling.

Step 1 Identify the bottleneck first (quick checklist)
Most slow/buggy Lightning UIs come from one (or more) of these:

Too many Apex calls (N+1 calls, call per row, call per keystroke) 2.Returning too much data (querying 10k+ records, too many fields)
No pagination / no server-side filtering
No caching (@AuraEnabled(cacheable=true) missing)
Bad state management (re-render loops, heavy getters, repeated array cloning)
Missing error handling (uncaught promise errors → blank UI / red error) 7.Inefficient SOQL (non-selective filters, no indexes, sorting huge sets) We’ll fix these with a solid baseline architecture.

Step 2 Fix Apex: cacheable + paginated + minimal fields
Apex Controller (server-side pagination + search)
This avoids loading thousands of rows and keeps the UI fast.
ContactBrowserController.cls
`public with sharing class ContactBrowserController {
public class PageResult {
@AuraEnabled public List records;
@AuraEnabled public Integer total;
@AuraEnabled public String nextCursor; // for keyset pagination (optional)
}

@AuraEnabled(cacheable=true)
public static PageResult fetchContacts(Integer pageSize, Integer pageNumber, String searchKey) {
    pageSize = (pageSize == null || pageSize <= 0) ? 25 : Math.min(pageSize, 200);
    pageNumber = (pageNumber == null || pageNumber <= 0) ? 1 : pageNumber;

    String likeKey = String.isBlank(searchKey) ? null : ('%' + searchKey.trim() + '%');

    // Count query (for pagination UI)
    Integer totalCount;
    if (likeKey == null) {
        totalCount = [SELECT COUNT() FROM Contact WHERE IsDeleted = false];
    } else {
        totalCount = [
            SELECT COUNT()
            FROM Contact
            WHERE IsDeleted = false
            AND (Name LIKE :likeKey OR Email LIKE :likeKey)
        ];
    }

    Integer offsetRows = (pageNumber - 1) * pageSize;

    List<Contact> rows;
    if (likeKey == null) {
        rows = [
            SELECT Id, Name, Email, Phone, Account.Name
            FROM Contact
            WHERE IsDeleted = false
            ORDER BY LastModifiedDate DESC
            LIMIT :pageSize OFFSET :offsetRows
        ];
    } else {
        rows = [
            SELECT Id, Name, Email, Phone, Account.Name
            FROM Contact
            WHERE IsDeleted = false
            AND (Name LIKE :likeKey OR Email LIKE :likeKey)
            ORDER BY LastModifiedDate DESC
            LIMIT :pageSize OFFSET :offsetRows
        ];
    }

    PageResult result = new PageResult();
    result.records = rows;
    result.total = totalCount;
    result.nextCursor = null; // kept for future keyset approach
    return result;
}

Why this helps
• You fetch only what you need (small page).
• You limit fields (fewer bytes, faster).
• You cache results for identical parameters.
Note: OFFSET can become slow at very high page numbers. If you need huge datasets, move to keyset pagination (cursor based). I can provide that too.

Step 3 LWC: debounce search + show spinner + handle errors
LWC HTML (datatable + search + paging)
contactBrowser.html

<template>
    <lightning-card title="Contacts" icon-name="standard:contact">
        <div class="slds-p-horizontal_medium slds-p-top_small">
            <lightning-input
                type="search"
                label="Search (Name or Email)"
                value={searchKey}
                onchange={handleSearchChange}>
            </lightning-input>

            <template if:true={isLoading}>
                <div class="slds-m-top_small">
                    <lightning-spinner alternative-text="Loading..." size="small"></lightning-spinner>
                </div>
            </template>

            <template if:true={errorMessage}>
                <div class="slds-m-top_small slds-text-color_error">
                    {errorMessage}
                </div>
            </template>

            <lightning-datatable
                key-field="Id"
                data={rows}
                columns={columns}
                hide-checkbox-column
                class="slds-m-top_small">
            </lightning-datatable>

            <div class="slds-m-top_small slds-grid slds-grid_align-spread slds-grid_vertical-align-center">
                <div>
                    Page {pageNumber} of {totalPages} • Total: {total}
                </div>

                <div class="slds-button-group" role="group">
                    <lightning-button label="Prev" onclick={prevPage} disabled={disablePrev}></lightning-button>
                    <lightning-button label="Next" onclick={nextPage} disabled={disableNext}></lightning-button>
                </div>
            </div>
        </div>
    </lightning-card>
</template>

LWC JS (imperative Apex + debounce + safe state updates)
contactBrowser.js

import { LightningElement, track } from 'lwc';
import fetchContacts from '@salesforce/apex/ContactBrowserController.fetchContacts';
import { ShowToastEvent } from 'lightning/platformShowToastEvent';

export default class ContactBrowser extends LightningElement {
    columns = [
        { label: 'Name', fieldName: 'Name' },
        { label: 'Email', fieldName: 'Email' },
        { label: 'Phone', fieldName: 'Phone' },
        { label: 'Account', fieldName: 'AccountName' }
    ];

    @track rows = [];
    total = 0;

    pageSize = 25;
    pageNumber = 1;

    searchKey = '';
    isLoading = false;
    errorMessage = '';

    debounceTimer;

    connectedCallback() {
        this.load();
    }

    get totalPages() {
        return Math.max(1, Math.ceil(this.total / this.pageSize));
    }

    get disablePrev() {
        return this.pageNumber <= 1 || this.isLoading;
    }

    get disableNext() {
        return this.pageNumber >= this.totalPages || this.isLoading;
    }

    async load() {
        this.isLoading = true;
        this.errorMessage = '';

        try {
            const res = await fetchContacts({
                pageSize: this.pageSize,
                pageNumber: this.pageNumber,
                searchKey: this.searchKey
            });

            // Flatten Account.Name for datatable
            this.rows = (res.records || []).map(r => ({
                ...r,
                AccountName: r.Account ? r.Account.Name : ''
            }));
            this.total = res.total || 0;

            // Clamp pageNumber if total changed drastically
            if (this.pageNumber > this.totalPages) {
                this.pageNumber = this.totalPages;
            }
        } catch (e) {
            this.errorMessage = this.reduceError(e);
            this.rows = [];
            this.total = 0;

            this.dispatchEvent(
                new ShowToastEvent({
                    title: 'Error loading contacts',
                    message: this.errorMessage,
                    variant: 'error'
                })
            );
        } finally {
            this.isLoading = false;
        }
    }

    handleSearchChange(event) {
        this.searchKey = event.target.value;

        // Debounce to avoid Apex call on every keystroke
        window.clearTimeout(this.debounceTimer);
        this.debounceTimer = window.setTimeout(() => {
            this.pageNumber = 1;
            this.load();
        }, 400);
    }

    nextPage() {
        if (this.pageNumber < this.totalPages) {
            this.pageNumber += 1;
            this.load();
        }
    }

    prevPage() {
        if (this.pageNumber > 1) {
            this.pageNumber -= 1;
            this.load();
        }
    }

    reduceError(e) {
        // Works for Apex + JS errors
        if (Array.isArray(e?.body)) return e.body.map(x => x.message).join(', ');
        return e?.body?.message || e?.message || 'Unknown error';
    }
}

What these fixes
• Debounce prevents “Apex call per keystroke”
• Spinner prevents “UI looks frozen”
• Toast + error message prevents “silent failure”
• Pagination prevents huge dataset rendering

Step 4 Fix common performance killers (must-do rules)
Rule A: Don’t call Apex in loops
Bad: call Apex once per row
Good: one Apex call returns all needed data for the page.

Rule B: Query only needed fields
Every extra field increases payload size and JSON parse time.

Rule C: Prefer cacheable reads
Use:
• @AuraEnabled(cacheable=true) for read methods
• refreshApex() when you actually need a refresh (wired approach)

Rule D: Avoid heavy getters causing re-render storms
If your getter does heavy logic or map/filter each render, move that computation to a one-time transform in load().

Step 5 If you’re using Aura: add client-side caching + proper error handling
Aura server action caching (storable)

// Aura controller
let action = component.get("c.fetchContacts");
action.setParams({ pageSize: 25, pageNumber: 1, searchKey: '' });

// Cache response (works for cacheable methods)
action.setStorable();

action.setCallback(this, function(response){
    let state = response.getState();
    if(state === "SUCCESS"){
        component.set("v.rows", response.getReturnValue().records);
    } else {
        let errors = response.getError();
        // show toast / log
    }
});
$A.enqueueAction(action);

Step 6 Add a “large data” safety net
When datasets get large, do these:
1.Server-side pagination (already done)
2.Limit pageSize (cap at 200)
3.Consider keyset pagination (cursor based) instead of OFFSET for deep paging
4.Ensure SOQL filters are selective (indexed fields where possible)

Step 7 Quick “production-grade” checklist
• Apex read methods are cacheable=true
• UI uses pagination / infinite scroll (not loading all)
• Search is debounced
• Handle errors with toast + user-friendly message
• Avoid repeated Apex calls; combine queries where possible
• Flatten/transform data once (not repeatedly in getters)
• Validate SOQL selectivity (especially in production volume)

Conclusion
LWC/Aura UI bugs and performance bottlenecks usually happen when components try to load too much data at once, make too many Apex calls, or fail to manage state and errors properly. What works fine with small sandbox data often breaks in production when record volumes grow and network/API delays increase.
To fix this reliably:
• Move heavy work to the server and use server-side filtering + pagination instead of loading thousands of rows.
• Mark read-only Apex methods as @AuraEnabled(cacheable=true) to reduce repeat calls and speed up rendering.
• Prevent unnecessary calls by using debounced search, avoiding Apex calls inside loops, and keeping the UI state minimal.
• Always include proper error handling (try/catch, toast messages, fallback UI) so runtime failures don’t crash the component silently.
• Query only the fields you actually need and use efficient SOQL to keep response payloads small and fast.

Salesforce Sandbox vs Production Configuration Drift

Selavina B — Wed, 10 Dec 2025 12:36:57 +0000

Problem statement: Features that work correctly in sandbox behave differently in production because of differences in metadata, data volume, automation, or integrations, making bugs hard to reproduce and increasing deployment risk.

1 Understand the types of Sandbox vs Prod Drift

Most of your issues will be in 4 buckets:

Metadata drift

Different Flows, Validation Rules, Page Layouts, Triggers, Profiles, Permission Sets, Record Types, etc.

Data drift

Sandbox has tiny, clean data.

Prod has large volume, nulls, weird values, old records.

Automation drift

Different Flows active/inactive

Different scheduled jobs, batch classes running

Different integrations enabled

Environment-specific config

Different endpoints, API keys, Named Credentials, feature toggles.

We’ll attack all 4.

2 Step 1 – Stop “clicking directly” in Production

Hard truth:
If admins/devs change things directly in production (Flows, fields, page layouts) that are not in sandbox → you will have drift.

Policy to adopt

All metadata changes:

Design & build in sandbox

Commit to Git

Deploy to Prod from source/metadata (SFDX, CI, or at least change sets).

Direct production-only changes = strictly forbidden (except hotfix, then back-port to sandbox).

3 Step 2 – Use SFDX + Git to compare sandbox vs prod

You can literally see the differences between orgs.

3.1 Setup SFDX project (once)
`# Create project
sfdx force:project:create -n my-salesforce-project
cd my-salesforce-project

Authorize orgs

sfdx auth:web:login -a DevSandbox
sfdx auth:web:login -a ProdOrg`

3.2 Retrieve metadata from both orgs

Pick important metadata types in manifest/package.xml (ApexClass, ApexTrigger, Flow, ValidationRule via CustomObject, PermissionSet, etc.)

Example manifest/package.xml snippet:

<?xml version="1.0" encoding="UTF-8"?> <Package xmlns="http://soap.sforce.com/2006/04/metadata"> <types> <members>*</members> <name>ApexClass</name> </types> <types> <members>*</members> <name>ApexTrigger</name> </types> <types> <members>*</members> <name>Flow</name> </types> <types> <members>*</members> <name>Profile</name> </types> <types> <members>*</members> <name>PermissionSet</name> </types> <types> <members>*</members> <name>CustomObject</name> </types> <version>59.0</version> </Package>

Then:

`# Retrieve from sandbox
sfdx force:source:retrieve -x manifest/package.xml -u DevSandbox -w 10

Copy this folder (or branch) as "prod" version:

git checkout -b sandbox-version
git add .
git commit -m "Sandbox metadata snapshot"

Retrieve from production (in another branch)

git checkout -b prod-version
sfdx force:source:retrieve -x manifest/package.xml -u ProdOrg -w 10
git add .
git commit -m "Production metadata snapshot"`

Now you can:

git diff sandbox-version..prod-version

…and literally see which Flows, Validation Rules, Triggers, Profiles differ.

This shows you where behavior differs.

4 Step 3 – Handle environment-specific configuration with Custom Metadata

Don’t hardcode “sandbox vs prod” in Apex. Use Custom Metadata / Custom Settings.

4.1 Create a Custom Metadata Type (UI)

Name: Environment_Config__mdt
Fields:

Environment_Name__c (Text)

Base_API_URL__c(Text)

Is_FeatureX_Enabled__c (Checkbox)

Create one record per org:

In sandbox:

Environment_Name__c = SANDBOX

Base_API_URL__c = https://sandbox-api.example.com

Is_FeatureX_Enabled__c = true

In prod:

Environment_Name__c = PROD

Base_API_URL__c =https://api.example.com

Is_FeatureX_Enabled__c = false (or as needed)

4.2 Apex helper to read config
`public with sharing class EnvConfigService {

private static Environment_Config__mdt config;

private static Environment_Config__mdt getConfig() {
    if (config == null) {
        config = [
            SELECT Environment_Name__c, Base_API_URL__c, Is_FeatureX_Enabled__c
            FROM Environment_Config__mdt
            LIMIT 1
        ];
    }
    return config;
}

public static String getBaseApiUrl() {
    return getConfig().Base_API_URL__c;
}

public static Boolean isFeatureXEnabled() {
    return getConfig().Is_FeatureX_Enabled__c;
}

public static String getEnvironmentName() {
    return getConfig().Environment_Name__c;
}

}
4.3 Use it in your logicpublic with sharing class ExternalSyncService {

public static void sendOrderToExternalSystem(Id orderId) {
    String baseUrl = EnvConfigService.getBaseApiUrl();
    if (String.isBlank(baseUrl)) {
        // Log & skip in misconfigured orgs
        System.debug('Base API URL not configured');
        return;
    }

    // callout code here ...
    // HttpRequest req = new HttpRequest();
    // req.setEndpoint(baseUrl + '/orders/' + orderId);
}

Now:

Sandbox and production can use different endpoints, toggles, etc.

You do NOT need to if/else on System.URL.getOrgDomainUrl() or similar hacks.

5 Step 4 – Align automation (Flows, Scheduled Jobs, Triggers)

A very common source of drift:

Flow active in sandbox, inactive in prod (or vice versa)

Scheduled job running in prod but not sandbox

Old trigger still active in prod but removed/disabled in sandbox

5.1 See scheduled jobs with Apex

Run this in Execute Anonymous (both orgs):

`List jobs = [
SELECT Id, CronJobDetail.Name, State, NextFireTime
FROM CronTrigger
ORDER BY NextFireTime
];

for (CronTrigger ct : jobs) {
System.debug('Job: ' + ct.CronJobDetail.Name +
' | State: ' + ct.State +
' | NextFire: ' + ct.NextFireTime);
}`

Compare sandbox vs production list → you’ll see which scheduled jobs differ.

5.2 Flow & Trigger status

These are metadata; best is to compare via SFDX / Git (Step 2). Key things:

For Flows:

Same versions should be Active in both orgs.

For Apex Triggers:

Same triggers should be Active/Inactive consistently.

If sandbox has a newer active Flow version than prod, then of course behavior differs.

6 Step 5 – Use realistic data sets (data volume + edge cases)

In sandbox, things work with 10 test records. In prod, there are 1M records, null fields, weird values.

Solution: seed sandbox with better data.

Option A – Use Full / Partial sandbox

Prefer at least one Partial or Full sandbox where data is closer to prod.

Option B – Seed data via script or test factory

Small Apex script to create “heavy” data scenario:

`// Execute Anonymous in sandbox

Account parent = new Account(Name = 'Parent Account');
insert parent;

List manyAccs = new List();
for (Integer i = 0; i < 5000; i++) {
manyAccs.add(new Account(
Name = 'Test Account ' + i,
ParentId = parent.Id,
Industry = (i % 2 == 0) ? 'Banking' : null // some nulls
));
}
insert manyAccs;`

This will help reveal performance or logic issues that only appear at scale.

7 Step 6 – Add environment-aware logging to debug differences

When behavior differs, you want quick visibility in prod without relying only on debug logs.

7.1 Create a simple Log__c object

Custom Object: Log__c

Fields:

Level__c (Picklist: INFO, WARN, ERROR)

Location__c (Text) – class/method name

Message__c (Long Text)

Context__c (Long Text) – JSON of important variables

Environment__c (Formula) referencing config or OrganizationType

7.2 Apex logging helper
`public with sharing class LogService {

public static void info(String location, String message, String contextJson) {
    insertLog('INFO', location, message, contextJson);
}

public static void error(String location, String message, String contextJson) {
    insertLog('ERROR', location, message, contextJson);
}

private static void insertLog(String level, String location, String message, String contextJson) {
    try {
        Log__c log = new Log__c(
            Level__c = level,
            Location__c = location,
            Message__c = message,
            Context__c = contextJson
        );
        insert log;
    } catch (Exception e) {
        // Avoid recursive logging failures
        System.debug('Failed to insert log: ' + e.getMessage());
    }
}

7.3 Use it in critical code paths
`public with sharing class OrderService {

public static void processOrder(Id orderId) {
    try {
        Order__c ord = [
            SELECT Id, Status__c, Amount__c
            FROM Order__c
            WHERE Id = :orderId
        ];

        LogService.info(
            'OrderService.processOrder',
            'Starting order processing',
            JSON.serialize(ord)
        );

        // ... processing logic ...

    } catch (Exception e) {
        LogService.error(
            'OrderService.processOrder',
            'Error while processing order: ' + e.getMessage(),
            '{"orderId":"' + String.valueOf(orderId) + '"}'
        );
        throw e;
    }
}

Now you can compare logs from sandbox vs prod to see exactly where behavior diverges.

8 Step 7 – Add a “pre-deployment checklist” for drift

Before any deploy:

Metadata alignment

SFDX diff for key components: Flows, Triggers, Classes, Validation Rules, Permission Sets.

Automation alignment

Same scheduled jobs?

Same active Flow versions?

Environment config

Custom Metadata / Named Credentials set correctly?

Smoke tests

Run a small script in sandbox and prod (read/write a test record, call critical logic) and compare behavior/logs.

Even a simple Apex smoke test method helps:

`@IsTest
private class SmokeTest {

@IsTest
static void testCoreLogic() {
    // create data, call main service methods, assert no exceptions
}

Run this in every org.

Conclusion – Controlling Sandbox vs Production Drift

Your problem isn’t random:

Features behave differently in sandbox and production when metadata, data, automation, and environment config drift apart.

To fix this reliably:

Centralize metadata in Git + SFDX and deploy from source, not random clicks.

Use Custom Metadata/Settings for environment-specific URLs, flags, and config.

Keep Flows, Triggers, and scheduled jobs aligned using metadata diffs and org comparisons.

Seed sandbox with realistic data to catch scale and null issues earlier.

Add logging + a pre-deployment checklist so you can see and prevent differences before they reach users.