Restriction Rules vs. Scoping Rules in Salesforce

 

Both Restriction Rules and Scoping Rules are used to control record visibility, but they serve different purposes.

1. Restriction Rules (Limit Record Access)

🔹 Purpose: Restrict the records a user can access beyond the existing org-wide defaults (OWD), sharing rules, or role hierarchy.
🔹 Effect:

• Prevents users from viewing, searching, or reporting on certain records.
• Works in List Views, Lookups, Reports, and Searches.
• Only allows users to see records that match the restriction rule conditions.

🔹 Key Characteristics:
 Works on Standard & Custom Objects (e.g., Cases, Contracts, Opportunities, Custom Objects).
 Applied on top of existing sharing rules to further restrict access.
 Controlled using User Criteria (Profile, Role, or Permission Set) + Record Field Conditions.

🔹 Example Use Case:
A support agent should only see Cases assigned to their region, even if the role hierarchy would otherwise allow them to see all cases.

2. Scoping Rules (Improve Data Filtering)

🔹 Purpose: Filter records a user sees by default in Lookups and List Views without restricting access.
🔹 Effect:

• Users can still search and access all records they have permission to see.
• Helps users focus on relevant records without removing access.

🔹 Key Characteristics:
 Only affects default filtering, not actual permissions.
 Users can manually remove the filter to see all accessible records.
 Does not apply to Reports, Global Search, or SOQL queries.
Set using User Criteria (Profile, Role, Permission Set) + Record Field Conditions.

🔹 Example Use Case:
A sales rep should see only open Opportunities in their region by default, but they can still search for all opportunities they have access to.

Key Differences

Feature	Restriction Rules 🔒	Scoping Rules 🔍
Purpose	Limits access to records	Improves record filtering
Effect	Hides records completely	Sets default filters (users can remove)
Applies To	List Views, Lookups, Reports, Searches	List Views, Lookups
Impact on Access	Users cannot access restricted records	Users can remove filter to see all records they have access to
Use Case	Hide sensitive customer cases from unauthorized users	Show only open deals by default for sales reps

When to Use Which?

✔ Use Restriction Rules when you need to enforce security and ensure that users cannot access certain records at all.
✔ Use Scoping Rules when you want to filter records for a better user experience but still allow full access when needed.

 

Types of Salesforce Integration Architectures

 

Types of Salesforce Integration Architectures

Salesforce offers several integration architectures, each with its own advantages and challenges. The three main types of integration architectures are:

1. Point-to-Point Integration
2. Hub-and-Spoke Integration
3. Enterprise Service Bus (ESB) Integration

1. Point-to-Point Integration

Also known as one-to-one integration, this method establishes a direct connection between two systems. For example, a sales application might send order information separately to a billing system, a shipping application, and a tracking system. If the tracking and shipping systems need to communicate, another integration must be created.

Drawbacks of Point-to-Point Integration:

• High Maintenance Costs: Each new connection requires additional development and maintenance.
• Scalability Issues: Adding or replacing systems requires multiple new integrations.
• Increased Complexity: As the number of integrations grows, managing dependencies becomes challenging.

---

2. Hub-and-Spoke Integration

This model introduces a central hub that acts as an intermediary for data exchange between different systems. Instead of creating multiple direct connections, each system only needs to connect to the hub.

Advantages of Hub-and-Spoke Integration:

• Simplified Connectivity: Each system integrates only with the hub, reducing complexity.
• Easier Scalability: Adding new systems requires just one new connection to the hub.
• Improved Maintenance: Changes can be managed centrally rather than modifying multiple integrations.

---

3. Enterprise Service Bus (ESB) Integration

The Enterprise Service Bus (ESB) is an advanced version of the Hub-and-Spoke model. It introduces an integration engine that facilitates seamless communication between systems by managing data transformation, orchestration, and routing.

Key Features of ESB Integration:

• Routing: Directs messages between systems based on predefined logic.
• Orchestration: Ensures transactions occur in a specific sequence, such as processing an order before sending shipping details.
• Data Transformation: Converts data formats between different systems to ensure compatibility.
• Security: Provides authentication and authorization mechanisms to enhance security.

With ESB, each system connects to the integration bus via an adapter, allowing for easy scalability as integration needs evolve.

---

Choosing the Right Integration Architecture

The best integration approach depends on your business needs, scalability requirements, and system complexity:

• Use Point-to-Point Integration for small-scale, simple connections where minimal systems interact.
• Use Hub-and-Spoke Integration for moderate scalability with a need for centralized control.
• Use ESB Integration for large-scale, enterprise-level integrations that require flexibility, security, and transformation capabilities.

By selecting the appropriate architecture, organizations can streamline their Salesforce integrations while ensuring long-term maintainability and efficiency.

Impact Analysis for Salesforce Development Team

 🔥 What is Impact Analysis? 🔥

 

In Salesforce, custom metadata components like fields, Apex classes, and page layouts rarely exist in isolation. They are often interconnected and influence multiple business processes. Understanding these dependencies is critical when planning development or deployment.

 

Some examples of relationships between metadata components include:

Ø  Custom Fields: Referenced in page layouts, Apex classes, and email templates.

Ø  Email Templates: Used in workflow alerts, approval processes, or Apex logic.

Ø  Apex Classes: Called by Visualforce pages, Lightning components, and triggers.

 

Effective impact analysis enables teams to identify potential risks and prevent disruptions caused by metadata changes, ensuring smooth development and deployment.

Key Areas of Analysis and Recommended Tools:

 

  

What Is a Deployment Boundary in Salesforce?

As a Salesforce Technical Architect, understanding deployment boundaries is critical for ensuring successful development and deployment processes. A deployment boundary encompasses all metadata required for a specific feature or configuration to function correctly within an org.

Example Scenario: Workflow Rule with an Email Alert

Consider a Workflow Rule that triggers an Email Alert when a Custom Field on the Account object meets a specific condition. To ensure this rule operates correctly after deployment, the following metadata dependencies must be included:

• Evaluated Object: The core object being assessed, such as Account or a custom object.
• Custom Fields: Fields referenced in evaluation criteria, including any dependent formula fields and their source fields.
• Email Template: The template used by the Email Alert.
• Referenced Fields: Any custom fields referenced within the email template content.

By clearly defining and capturing these metadata relationships, deployment boundaries help mitigate deployment failures, maintain feature integrity, and streamline release management.

 

For more Details

https://www.technoeric.in/2025/02/impact-analysis-for-salesforce.html

 

What is throw new CustomException() in Salesforce?

What is a Custom Exception?

In Apex, an exception is an error condition that can be thrown to interrupt normal program flow. By default, Salesforce provides common exceptions like DmlException, QueryException, etc. However, sometimes you may want to define your own exception types that are specific to your application’s business logic. This is where custom exceptions come in.

A custom exception extends the Exception class and allows you to define your own error message, and optionally, methods to manipulate or log information specific to the error.

---

Why Use Custom Exceptions?

• Separation of Concerns: Custom exceptions let you define specific error cases that your code handles, isolating errors for easy troubleshooting.
• Meaningful Error Messages: You can include custom messages that provide more context about what went wrong.
• Clearer Logic: With custom exceptions, you can add specific logic that handles different error types in a precise manner.

---

Basic Syntax:

To define a custom exception, you create a class that extends the Exception class, like so:

apex

public class MyCustomException extends Exception {
    // You can add custom fields or methods if needed
}

Once the exception is defined, you can throw it using throw new MyCustomException('Error message'), and it can be caught in a try-catch block.

---

Example 1: Simple Custom Exception

Custom Exception Class

apex

public class InvalidAccountException extends Exception {}

Apex Class with Custom Exception

apex

public class AccountService {
    public static void createAccount(String accName) {
        if (String.isBlank(accName)) {
            throw new InvalidAccountException('Account Name cannot be blank.');
        }
        // Code to create an account...
    }
}

Test Class for Custom Exception

In the test class, you can simulate an error condition that will trigger the exception.

apex

@isTest
public class AccountServiceTest {
    @isTest
    static void testInvalidAccountName() {
        try {
            // This should trigger the InvalidAccountException because the account name is blank
            AccountService.createAccount('');
            System.assert(false, 'Expected InvalidAccountException to be thrown');
        } catch (InvalidAccountException e) {
            // Assert that the exception message is correct
            System.assertEquals('Account Name cannot be blank.', e.getMessage());
        }
    }
}

---

Example 2: Custom Exception with Additional Properties

You can enhance custom exceptions by adding properties or methods to carry additional context information.

Custom Exception with Additional Properties

apex

public class InsufficientBalanceException extends Exception {
    public Decimal balance { get; set; }

    // Constructor that accepts balance
    public InsufficientBalanceException(String message, Decimal balance) {
        super(message);
        this.balance = balance;
    }
}

Apex Class Using This Exception

apex

public class BankService {
    public static void withdraw(Decimal amount, Decimal balance) {
        if (amount > balance) {
            throw new InsufficientBalanceException('Insufficient balance for withdrawal.', balance);
        }
        // Code to process the withdrawal...
    }
}

Test Class for the Enhanced Custom Exception

apex

@isTest
public class BankServiceTest {
    @isTest
    static void testInsufficientBalance() {
        Decimal accountBalance = 100.00;
        Decimal withdrawalAmount = 200.00;
        
        try {
            // This should trigger the InsufficientBalanceException
            BankService.withdraw(withdrawalAmount, accountBalance);
            System.assert(false, 'Expected InsufficientBalanceException to be thrown');
        } catch (InsufficientBalanceException e) {
            // Assert that the exception message and balance are correct
            System.assertEquals('Insufficient balance for withdrawal.', e.getMessage());
            System.assertEquals(accountBalance, e.balance);
        }
    }
}

---

Example 3: Custom Exception with Logging

In some cases, you may want to log the exception details to a custom object for auditing purposes. You can include such logic in your custom exception class.

Custom Exception with Logging

apex

public class DatabaseException extends Exception {
    public String query { get; set; }

    public DatabaseException(String message, String query) {
        super(message);
        this.query = query;
    }

    // Log the exception to a custom object for tracking
    public void logToDatabase() {
        DatabaseErrorLog__c errorLog = new DatabaseErrorLog__c(
            Error_Message__c = this.getMessage(),
            Query__c = this.query,
            CreatedDate__c = System.now()
        );
        insert errorLog;
    }
}

Apex Class Using This Exception

apex

public class DataService {
    public static void executeQuery(String query) {
        try {
            // Simulate a query execution failure
            throw new DatabaseException('Query failed due to unknown reasons', query);
        } catch (DatabaseException e) {
            // Log the error in a custom object
            e.logToDatabase();
            throw e; // Re-throw to propagate the exception if needed
        }
    }
}

Test Class for the Logging Custom Exception

apex

@isTest
public class DataServiceTest {
    @isTest
    static void testDatabaseExceptionLogging() {
        String query = 'SELECT Id FROM Account WHERE Name = "NonExistentAccount"';
        
        try {
            DataService.executeQuery(query);
            System.assert(false, 'Expected DatabaseException to be thrown');
        } catch (DatabaseException e) {
            // Assert that the custom exception message is correct
            System.assertEquals('Query failed due to unknown reasons', e.getMessage());
            
            // Verify the error log was created
            List<DatabaseErrorLog__c> logs = [SELECT Id FROM DatabaseErrorLog__c WHERE Query__c = :query];
            System.assertEquals(1, logs.size(), 'Error log should be created');
        }
    }
}

---

Example 4: Custom Exception with Multiple Catch Blocks

If your application needs to handle multiple types of exceptions (e.g., DmlException, QueryException, etc.), you can create several custom exceptions to handle specific cases.

Custom Exception for DML Errors

apex

public class CustomDmlException extends Exception {
    public CustomDmlException(String message) {
        super(message);
    }
}

Apex Code Handling DML Exceptions

apex

public class AccountService {
    public static void insertAccount(Account acc) {
        try {
            insert acc;
        } catch (DmlException e) {
            throw new CustomDmlException('DML operation failed: ' + e.getMessage());
        }
    }
}

Test Class for DML Exception

apex
@isTest
public class AccountServiceTest {
    @isTest
    static void testCustomDmlException() {
        Account invalidAccount = new Account(); // Missing required Name field
        
        try {
            AccountService.insertAccount(invalidAccount);
            System.assert(false, 'Expected CustomDmlException to be thrown');
        } catch (CustomDmlException e) {
            System.assert(e.getMessage().contains('DML operation failed'), 'Error message should contain DML failure');
        }
    }
}

---

Summary of Key Benefits of Custom Exceptions:

1. Clarity in Error Handling: Custom exceptions provide more meaningful error messages specific to your business logic.
2. Contextual Information: You can pass additional context (e.g., query, balance) with custom exceptions.
3. Custom Handling: You can add logic to handle exceptions more gracefully, like logging, custom alerts, etc.
4. Better Maintainability: By naming exceptions appropriately, you make the code easier to maintain and debug.

---

By using custom exceptions, you can write more efficient, understandable, and maintainable Apex code. They help ensure that specific errors are caught and handled in a way that is relevant to your application’s needs.