# Developer Fundamentals ### **1.1 Data Modeling and Management** #### **Core Concepts** ##### **1. Object Model** **What is an Object?** - An **object** in Salesforce is like a database table that stores specific information. - Each object contains **fields** (columns in a database) and **records** (rows in a database). ##### **Types of Objects** 1. **Standard Objects**: - Predefined by Salesforce to represent common data structures. - Examples: - **Account**: Represents companies or individuals you're working with. - **Contact**: Stores details of people related to accounts. - **Opportunity**: Tracks sales deals in progress. - **Case**: Manages customer support issues. - You cannot delete standard objects, but you can customize them. 2. **Custom Objects**: - Created by users for specific business needs. - Examples: - **Student**: For schools, a custom object might track student details. - **Order**: For businesses, it might track customer purchases. - Features: - Custom fields, relationships, and layouts can be added. - Custom objects have a "__c" suffix in their API name (e.g., `Student__c`). ##### **Schema Builder** - **What is Schema Builder?** - A drag-and-drop tool in Salesforce that visually represents objects and their relationships. - Found in: **Setup > Object Manager > Schema Builder**. - **Why Use Schema Builder?** - Helps you visualize the structure of objects and fields. - Makes it easy to create or modify objects and relationships. ##### **2. Field Types** Fields are the building blocks of an object, representing the data stored in it. Salesforce provides different field types for flexibility: 1. **Scalar Fields**: - Basic fields to store single values. - Examples: - **Text**: Stores alphanumeric data. - **Number**: Stores numeric values (e.g., 42, 3.14). - **Date**: Stores calendar dates (e.g., 2024-01-01). 2. **Formula Fields**: - Automatically calculate values based on other fields or formulas. - Example: - **Formula**: Calculate an employee's age from their date of birth: ```formula TODAY() - Birthdate ``` 3. **Relationship Fields**: - Link one object to another for creating relationships. - Types of Relationships: - **Lookup**: - Creates a loose connection between objects. - The field can be null. - Example: A Contact can look up to an Account. - **Master-Detail**: - Creates a strong connection between objects. - If the parent is deleted, the child is also deleted. - Example: Invoice Line Items (child) are tied to an Invoice (parent). - **Many-to-Many**: - Allows linking of multiple records from two objects. - Achieved using a **Junction Object**. - Example: A custom object `Project__c` can have multiple employees and vice versa. ##### **3. Design Tips** 1. **Choose Field Types Wisely**: - Use **Number** instead of **Text** for numeric data to support calculations. - Use **Picklists** for predefined options to maintain consistency. 2. **Avoid Deeply Nested Relationships**: - Too many Master-Detail relationships create dependency complexity. - Limit nesting levels to improve performance and maintainability. ### **1.2 Apex Programming Language** #### **Core Concepts** **What is Apex?** - Apex is Salesforce's proprietary programming language. - It's strongly-typed and object-oriented, meaning it enforces strict rules about data types and syntax. - Similar to Java, but designed to work within Salesforce's platform limits. ##### **Apex Syntax Basics** 1. **Variable Declaration**: - Stores values for processing. - Example: ```apex String name = 'John'; Integer age = 30; Boolean isActive = true; ``` 2. **Control Structures**: - Used for decision-making and iteration. - Examples: - `if-else`: ```apex if (age > 18) { System.debug('Adult'); } else { System.debug('Minor'); } ``` - `for loop`: ```apex for (Integer i = 0; i < 5; i++) { System.debug('Count: ' + i); } ``` 3. **Data Structures**: - **List**: An ordered collection of items. ```apex List names = new List{'John', 'Jane'}; ``` - **Set**: A collection of unique items. ```apex Set uniqueNumbers = new Set{1, 2, 3}; ``` - **Map**: Key-value pairs. ```apex Map students = new Map(); students.put(1, 'John'); ``` ##### **Methods and Classes** 1. **Static Methods**: - Can be called without creating an instance of a class. - Example: ```apex public class Utility { public static void sayHello() { System.debug('Hello, Salesforce!'); } } ``` 2. **Encapsulation**: - Use **access modifiers** to control the visibility of classes, methods, or variables: - `private`: Only accessible within the class. - `public`: Accessible anywhere. - `global`: Accessible across all namespaces. ##### **Triggers** **What is a Trigger?** - A Trigger automates actions in Salesforce when specific events occur, such as inserting or updating a record. - Example: ```apex trigger AccountTrigger on Account (before insert, after update) { for (Account acc : Trigger.new) { acc.Description = 'Auto-updated description'; } } ``` - **Best Practices**: - Avoid recursion by using static variables. - Use one trigger per object for simplicity. ### **1.3 SOQL and SOSL** #### **SOQL (Salesforce Object Query Language)** - Retrieves data from Salesforce. - Example: ```apex SELECT Id, Name FROM Account WHERE Industry = 'Technology' ``` #### **SOSL (Salesforce Object Search Language)** - Performs full-text searches across multiple objects. - Example: ```apex FIND 'Smith' IN Name Fields RETURNING Contact(Id, Name) ``` ### **1.4 Platform Limits (Governor Limits)** **Why Governor Limits?** - Salesforce uses multi-tenant architecture, meaning multiple organizations share the same resources. Limits ensure fair usage. **Examples of Limits**: - **SOQL Queries**: Max 100 per transaction. - **DML Operations**: Max 150 per transaction. - **CPU Time**: Max 10 seconds for synchronous operations. ### **1.5 Development Tools** 1. **Developer Console**: - Debug and test code directly in Salesforce. 2. **Salesforce CLI**: - Command-line tool for metadata management. 3. **Visual Studio Code (VS Code)**: - Modern IDE with Salesforce extensions for coding Apex and LWC. --- # Process Automation and Logic Salesforce provides tools for automating business processes, either declaratively (without code) or programmatically (using code). These tools allow you to meet various business requirements, from simple field updates to advanced workflows and asynchronous operations. ### **2.1 Declarative Automation** Declarative tools allow you to automate processes without writing code. They are user-friendly and ideal for many business scenarios. #### **1. Process Builder** - **What is Process Builder?** - A declarative tool for building simple business logic processes. - Found in **Setup > Process Builder**. - **Key Features**: - **Field Updates**: Automatically update a record’s field when a condition is met. - **Email Notifications**: Send emails based on record changes. - **Create Records**: Create related records as part of the process. - **Call Flow or Apex**: Trigger a flow or Apex code for more complex actions. - **Use Cases**: - Automatically change an Account's status to "Active" when the first Opportunity is closed. - Notify a sales rep when an Opportunity's amount exceeds $50,000. #### **2. Flow Builder** - **What is Flow Builder?** - A powerful tool for building complex workflows, forms, and automations. - Found in **Setup > Flows**. - **Key Features**: - **Dynamic Forms**: Display forms to collect user input. - **Multi-Step Processes**: Guide users through multiple steps. - **Integration**: Call Apex classes, send outbound messages, or query data using SOQL. - **Loops and Decisions**: Perform repeated actions (e.g., update multiple records) and make decisions based on conditions. - **Use Cases**: - Automate onboarding by guiding users through a multi-step employee setup process. - Automatically calculate discounts and apply them to related records. #### **3. Approval Processes** - **What is an Approval Process?** - A tool for automating multi-step approval workflows. - Found in **Setup > Approval Processes**. - **Key Features**: - **Steps**: Define who approves each step in the process. - **Actions**: - Field Updates: Change a field's value when approved or rejected. - Notifications: Send emails to approvers. - **Use Cases**: - Approve discount requests over 20%. - Approve job offers before sending them to candidates. ### **2.2 Programmatic Automation** Programmatic automation is used when declarative tools can’t meet the requirements. It provides advanced flexibility through coding. #### **Triggers** Triggers are pieces of code that execute automatically in response to database events, such as inserting, updating, or deleting records. - **Trigger Events**: 1. **Before Events**: - Logic runs before a record is saved to the database. - Common Use: Data validation or auto-populating fields. 2. **After Events**: - Logic runs after a record is saved. - Common Use: Updating related records or sending emails. ##### **Example Trigger** The following trigger updates the `Description` field of a `Contact` record before it is saved: ```apex trigger ContactTrigger on Contact (before insert) { for (Contact con : Trigger.new) { con.Description = 'Welcome, ' + con.FirstName; } } ``` **Explanation**: 1. `Trigger.new`: A list of records being processed. 2. The trigger iterates through each new `Contact` and updates its `Description` field. **Best Practices**: - Avoid recursion by using static variables. - Use one trigger per object for simplicity and maintainability. #### **Asynchronous Tasks** Asynchronous tasks handle time-consuming processes, such as processing large data sets or calling external APIs, without blocking the user. ##### **1. Future Methods** - **What are Future Methods?** - A lightweight way to run code asynchronously in the background. - Common Use: Callouts to external web services or operations that don’t need an immediate result. - **Example**: ```apex @future public static void sendEmail(String email) { // Logic to send email System.debug('Sending email to ' + email); } ``` - **Best Practices**: - Cannot return results. - Should be used sparingly; Queueable Apex is often preferred for chaining operations. ##### **2. Batch Apex** - **What is Batch Apex?** - Designed to process large volumes of records in chunks (up to 200 records per batch). - Common Use: Perform data cleanup, complex calculations, or updates on thousands of records. - **Key Components**: - `start`: Retrieves the data to be processed. - `execute`: Processes each batch of data. - `finish`: Executes post-processing logic. - **Example**: ```apex global class BatchExample implements Database.Batchable { global Database.QueryLocator start(Database.BatchableContext context) { return Database.getQueryLocator('SELECT Id FROM Account'); } global void execute(Database.BatchableContext context, List scope) { for (Account acc : scope) { acc.Description = 'Processed in batch'; } update scope; } global void finish(Database.BatchableContext context) { System.debug('Batch processing completed.'); } } ``` ##### **3. Queueable Apex** - **What is Queueable Apex?** - An enhancement of Future Methods, allowing chaining of multiple asynchronous operations. - **Features**: - Can pass complex objects as parameters. - Allows jobs to be linked sequentially. - **Example**: ```apex public class QueueableExample implements Queueable { public void execute(QueueableContext context) { System.debug('Executing asynchronous job'); } } ``` ##### **4. Scheduled Jobs** - **What are Scheduled Jobs?** - Executes recurring tasks at specific times using the `Schedulable` interface. - **Use Cases**: - Nightly data backups. - Weekly recalculations of metrics. - **Example**: ```apex global class ScheduledJob implements Schedulable { global void execute(SchedulableContext sc) { System.debug('Scheduled job executed'); } } ``` - To schedule: ```apex ScheduledJob job = new ScheduledJob(); String cron = '0 0 12 * * ?'; // Noon daily System.schedule('Daily Job', cron, job); ``` ### **Summary** Declarative automation tools are great for straightforward processes, while programmatic automation provides the power to handle complex or large-scale tasks. Combining these approaches ensures you can automate virtually any business scenario in Salesforce effectively. --- # User Interface Salesforce provides tools for creating user interfaces to manage and interact with data. These tools range from classic Visualforce pages to the modern Lightning Web Components (LWC) framework. ### **3.1 Visualforce** **What is Visualforce?** - Visualforce is a framework for building custom user interfaces in Salesforce. - It uses the `` markup language, similar to HTML, and integrates tightly with Salesforce’s backend. #### **Key Components of Visualforce** Visualforce pages are constructed using `` tags. 1. **``**: - The root tag for a Visualforce page. - Example: ```html

Welcome to Salesforce

``` 2. **``**: - Used to create forms for user input. - Example: ```html ``` 3. **``**: - An input field for capturing text from users. - Can be bound to an Apex variable or property. #### **Custom Controllers** Visualforce can use Apex classes to add dynamic behavior and logic to pages. - **What are Custom Controllers?** - An Apex class that acts as the backend for a Visualforce page. - Used to process user input, fetch data, or perform custom actions. - **Example**: Visualforce Page: ```html

Hello, {!name}!

``` Custom Controller (Apex Class): ```apex public class MyController { public String name { get; set; } public void greet() { System.debug('Greeting ' + name); } } ``` **Key Features of Visualforce**: - Works well for creating custom pages in Salesforce Classic. - Can be embedded in page layouts, tabs, or as standalone applications. - Limited compared to modern frameworks like LWC. ### **3.2 Lightning Web Components (LWC)** **What is LWC?** - Lightning Web Components (LWC) is a modern framework for building user interfaces. - It leverages web standards like HTML, JavaScript, and CSS. - Designed for better performance, faster development, and seamless integration with Salesforce data. #### **Key Features of LWC** 1. **Web Standards**: - Uses standard HTML and JavaScript, making it easier for developers to learn and build. 2. **Seamless Salesforce Integration**: - Directly connects to Salesforce objects and data via the Lightning Data Service (LDS). 3. **Reusable Components**: - LWC components can be reused across pages and applications. #### **Example of LWC** Let’s create a simple LWC component with a button that logs a message when clicked. 1. **HTML Template**: - The structure of the component is defined using an HTML template: ```html ``` 2. **JavaScript File**: - The behavior of the component is controlled using JavaScript: ```javascript import { LightningElement } from 'lwc'; export default class Example extends LightningElement { handleClick() { console.log('Button clicked'); } } ``` 3. **CSS File (Optional)**: - You can style the component using CSS. 4. **Deploying the Component**: - Once created, the component can be added to Salesforce pages via the Lightning App Builder. #### **When to Use LWC?** - When building modern, dynamic user interfaces. - For creating reusable components that work across Salesforce Lightning applications. - Ideal for performance-critical or scalable solutions. ### **3.3 User Experience Optimization** #### **Dynamic Forms** - **What are Dynamic Forms?** - Allow fields and sections to be displayed conditionally based on the record type, user, or other criteria. - Available for Lightning Record Pages. - **Use Case**: - Show a “Discount” field only when the “Account Type” is "Premium." #### **Optimizing Page Load Times** 1. **Reduce Server Calls**: - Minimize SOQL queries and avoid fetching unnecessary data. - Use lazy loading for components that don’t need to render immediately. 2. **Use Lightning Data Service (LDS)**: - Automatically manages data access and caching. - Reduces the need for Apex controllers. 3. **Efficient Component Design**: - Split large components into smaller, focused components. - Use `@wire` decorators for efficient data fetching. ### **Summary** - **Visualforce** is a legacy tool for building pages but is still relevant for some use cases. - **LWC** is the modern standard for creating dynamic and fast interfaces. - Optimizing the user experience through dynamic forms and efficient design ensures your applications perform well and meet user needs. --- # Testing, Debugging, and Deployment In Salesforce development, ensuring the quality and functionality of your code is essential. Testing and debugging help catch issues early, while deployment ensures that your work moves smoothly between environments. ### **4.1 Unit Testing** #### **What is Unit Testing in Salesforce?** - Unit testing involves writing test classes to validate the functionality of your Apex code (e.g., triggers, classes, methods). - Salesforce requires at least **75% code coverage** for all Apex classes and triggers before deploying to production. #### **Coverage Requirement** - **Why 75%?** - Salesforce enforces this threshold to ensure code quality and minimize errors in production environments. - While 75% is the minimum, aim for **100% coverage** where possible for better reliability. #### **How to Write a Test Class** A test class is an Apex class annotated with `@isTest` and contains test methods to verify code behavior. #### **Example Test Class** The following is a simple example of a test class for an `Account` trigger: **Trigger to Test:** ```apex trigger AccountTrigger on Account (before insert) { for (Account acc : Trigger.new) { acc.Description = 'Auto-generated Description'; } } ``` **Test Class:** ```apex @isTest public class AccountTest { @isTest static void testAccountTrigger() { // Create a new Account record Account acc = new Account(Name = 'Test Account'); insert acc; // Validate the trigger logic Account insertedAcc = [SELECT Description FROM Account WHERE Id = :acc.Id]; System.assertEquals('Auto-generated Description', insertedAcc.Description); } } ``` #### **Key Concepts in the Test Class** 1. **Setup Test Data**: - Create or query data to simulate real scenarios (e.g., creating an `Account` record). 2. **Invoke the Code**: - Perform DML operations (like `insert`, `update`) that trigger your code. 3. **Assert Results**: - Use `System.assert` methods to verify that the results match expectations. - Example: ```apex System.assertEquals(expected, actual); ``` #### **Best Practices for Unit Testing** - **Isolate Tests**: Each test method should focus on a single scenario or functionality. - **Avoid Hard-Coded IDs**: Use dynamic queries or `Test.loadData()` to populate data. - **Bulk Testing**: Ensure your code handles multiple records at once. - **Negative Testing**: Test invalid inputs or edge cases. ### **4.2 Debugging** Debugging helps identify and fix issues in your code during development. #### **Tools for Debugging** 1. **System.debug()**: - Outputs logs for analysis. - Example: ```apex System.debug('The value of acc.Description is: ' + acc.Description); ``` 2. **Developer Console**: - A built-in tool in Salesforce to view debug logs, analyze queries, and monitor performance. - To use: - Open **Developer Console**. - Go to **Debug > Open Execute Anonymous Window** to run Apex code. - View logs under **Debug > View Logs**. 3. **Debug Logs**: - Logs every step of your code execution. - **Log Levels**: - **Debug**: Logs detailed information for troubleshooting. - **Error**: Logs only errors. - **Event**: Logs significant system events. #### **Best Practices for Debugging** 1. **Add Meaningful Debug Statements**: - Provide context in your debug logs. - Example: ```apex System.debug('Processing Account record with ID: ' + acc.Id); ``` 2. **Filter Debug Logs**: - Use filters to focus on relevant information, especially in large logs. 3. **Leverage Developer Console Features**: - **Execution Overview**: View the execution order of methods, queries, and triggers. - **SOQL Analyzer**: Analyze and optimize queries. ### **4.3 Deployment** After developing and testing in a sandbox or developer environment, you need to deploy your changes to production or other sandboxes. #### **1. Change Sets** - **What are Change Sets?** - A tool in Salesforce to migrate metadata (e.g., Apex classes, triggers, objects) between environments. - Accessible via **Setup > Outbound Change Sets**. - **How to Use**: 1. Create an **Outbound Change Set** in the source org. 2. Add components (e.g., Apex classes, objects). 3. Upload the change set to the target org. 4. In the target org, validate and deploy the change set. - **Pros**: - Simple to use for basic deployments. - No external tools required. - **Cons**: - Limited to components supported by Salesforce. - Not suitable for complex deployment scenarios. #### **2. Salesforce DX (Developer Experience)** - **What is Salesforce DX?** - A modern development and deployment toolset designed for source-driven development. - Ideal for Continuous Integration/Continuous Deployment (CI/CD). - **Key Features**: - **Scratch Orgs**: Temporary, disposable environments for development and testing. - **CLI Commands**: Manage metadata, retrieve logs, and automate tasks. - **Version Control Integration**: Works seamlessly with Git for tracking changes. - **Deployment Workflow with Salesforce DX**: 1. Use the CLI to pull changes from a source org. 2. Commit changes to a version control system like Git. 3. Push changes to other orgs or environments. - **Example Deployment Command**: ```bash sfdx force:source:deploy -p path/to/metadata ``` #### **Comparison of Change Sets and Salesforce DX** | Feature | Change Sets | Salesforce DX | | ----------------- | ----------------------------- | --------------------------------- | | **Ease of Use** | Simple, GUI-based | Requires CLI and technical skills | | **Complexity** | Limited to supported metadata | Handles complex deployments | | **CI/CD Support** | No | Yes | | **Speed** | Manual process | Automated workflows | ### **Summary** - **Testing** ensures your code works as expected and meets Salesforce’s 75% coverage requirement. - **Debugging** is essential for troubleshooting and improving code quality. - **Deployment** tools like Change Sets and Salesforce DX streamline moving code between environments. --- # Developer Fundamentals (Additional Content) ### **1. Salesforce MVC Architecture** Salesforce follows the **Model-View-Controller (MVC) architecture**, which is a design pattern used to separate application logic, data, and user interfaces. This ensures better organization, scalability, and maintainability of the system. #### **1.1 Model (Data Layer)** The **Model** represents the **data and business logic** of the application. In Salesforce, the data layer is composed of the following: - **Standard Objects**: Predefined objects provided by Salesforce, such as `Account`, `Contact`, `Opportunity`, and `Case`. - **Custom Objects**: User-defined objects created to store organization-specific data. - **Fields**: Attributes of objects that store specific pieces of data, such as `Name`, `Email`, `Amount`, etc. - **Relationships**: Define how different objects are related to each other. The main types are: - **Lookup Relationships**: Loose connection between objects. - **Master-Detail Relationships**: Strong relationship where the child record depends on the parent. - **Junction Objects**: Used to create many-to-many relationships. #### **1.2 View (User Interface Layer)** The **View** is responsible for **displaying data to users and capturing user interactions**. In Salesforce, this includes: - **Lightning Pages**: Customizable UI layouts that display records and components. - **Visualforce Pages**: Custom pages built using `` tags, often used for complex UI needs in Salesforce Classic. - **Lightning Web Components (LWC)**: Modern UI components built using **HTML, JavaScript, and CSS** that provide dynamic and high-performance interfaces. #### **1.3 Controller (Logic Layer)** The **Controller** layer handles **business logic and user interactions**. In Salesforce, this consists of: - **Apex Classes**: Custom business logic implemented using the Apex programming language. - **Triggers**: Code that runs automatically when records are inserted, updated, or deleted. - **Workflows & Process Builder**: Declarative automation tools used for updating records and sending notifications. - **Flows**: A more powerful automation tool that allows multi-step processes, loops, and decisions. ### **2. Apex Security** Security is a critical part of Salesforce development, ensuring that data is accessed only by authorized users. Apex security mechanisms include **Field-Level Security (FLS), CRUD (Create, Read, Update, Delete) Permissions, and Sharing Rules**. #### **2.1 Field-Level Security (FLS)** - **FLS controls which fields users can view or edit.** - **Example**: A sales representative may see a customer’s email but not their salary. - Implemented via **Profiles, Permission Sets**, and **Apex code checks**. #### **2.2 CRUD Permissions** - **Defines whether a user can Create, Read, Update, or Delete records in an object.** - Best practice: **Enforce CRUD checks in Apex** to prevent unauthorized data access. - **Example: Checking Read Access** ```apex if (Schema.sObjectType.Account.fields.Industry.isAccessible()) { Account acc = [SELECT Industry FROM Account WHERE Id = :someId]; System.debug(acc.Industry); } else { System.debug('User does not have access to Industry field.'); } ``` #### **2.3 Sharing Rules and Apex Security Mode** Salesforce uses a **record-level security model** where users can access data based on **ownership and sharing rules**. - **With Sharing**: Enforces organization-wide sharing settings. - **Without Sharing**: Allows unrestricted data access (not recommended unless necessary). **Example: Enforcing Sharing Rules in Apex** ```apex public with sharing class SecureAccount { public static List getAccounts() { return [SELECT Id, Name FROM Account]; // Enforces record-level security } } ``` - **Without Sharing Example (Avoid unless necessary)**: ```apex public without sharing class AdminUtility { public static List getAllUsers() { return [SELECT Id, Name FROM User]; // Ignores sharing rules } } ``` ### **3. Asynchronous Apex** Asynchronous Apex allows operations to run in the **background**, preventing long-running processes from blocking user actions. #### **3.1 Future Methods** - **Best for short background tasks (e.g., external API calls).** - Cannot return values. - Example: ```apex public class AsyncExample { @future public static void processRecords(Set recordIds) { List accs = [SELECT Id, Name FROM Account WHERE Id IN :recordIds]; // Process data asynchronously } } ``` #### **3.2 Queueable Apex** - **Enhances Future Methods** by allowing complex objects and method chaining. - Example: ```apex public class QueueableExample implements Queueable { public void execute(QueueableContext context) { System.debug('Running Queueable Apex...'); } } ``` **To execute:** ```apex System.enqueueJob(new QueueableExample()); ``` #### **3.3 Batch Apex** - **Best for processing large datasets (up to millions of records).** - Example: ```apex global class BatchExample implements Database.Batchable { global Database.QueryLocator start(Database.BatchableContext bc) { return Database.getQueryLocator('SELECT Id FROM Account'); } global void execute(Database.BatchableContext bc, List scope) { for (Account acc : scope) { acc.Name += ' - Updated'; } update scope; } global void finish(Database.BatchableContext bc) { System.debug('Batch Job Finished'); } } ``` **To execute:** ```apex Database.executeBatch(new BatchExample()); ``` ### **4. Metadata API & Deployment** Salesforce provides **multiple ways** to deploy metadata between environments. #### **4.1 Metadata API** - **Used to import/export Salesforce metadata (e.g., objects, triggers, Apex code).** - Works through **SOAP-based API calls**. #### **4.2 Deployment Tools** | **Tool** | **Use Case** | | --- | --- | | **Change Sets** | UI-based tool for small deployments | | **Salesforce CLI (SFDX)** | For DevOps automation and CI/CD | | **GitHub Integration** | Version control for source-driven development | #### **4.3 Using SFDX for Deployment** Salesforce DX (SFDX) is a powerful CLI tool for automating metadata deployment. **Example: Deploying metadata with SFDX** 1. Authenticate to Salesforce: ```sh sfdx force:auth:web:login -r https://login.salesforce.com ``` 2. Deploy metadata: ```sh sfdx force:source:push -u MyDevOrg ``` 3. Retrieve latest metadata: ```sh sfdx force:source:pull -u MyDevOrg ``` #### **4.4 CI/CD in Salesforce** - **Continuous Integration/Continuous Deployment (CI/CD) automates deployments using tools like GitHub Actions, Jenkins, and Bitbucket Pipelines.** - Example GitHub Actions Workflow: ```yaml name: Deploy to Salesforce on: push jobs: deploy: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v2 - name: Deploy to Salesforce run: sfdx force:source:deploy -p force-app -u MyDevOrg ``` **CI/CD Benefits:** - Automates testing and deployment. - Ensures consistent, error-free releases. - Enhances team collaboration with version control. --- # Process Automation and Logic (Additional Content) ### **1. Workflow Rules** #### **What are Workflow Rules?** - Workflow Rules are an **older automation tool** in Salesforce, accessible via **Setup > Workflow Rules**. - They allow simple automation of record updates and notifications **without coding**. - **Limited functionality** compared to newer automation tools like Process Builder and Flow. #### **Capabilities of Workflow Rules** **Can do**: - Send email alerts. - Update a field’s value. - Create tasks. - Send outbound messages. **Cannot do**: - **Create new records** (use Flow instead). - **Call Apex code** (use Flow or Triggers). - **Perform multiple actions based on complex conditions** (Process Builder or Flow is required). #### **Workflow Rules vs. Process Builder** | Feature | Workflow Rules | Process Builder | | --- | --- | --- | | **Multiple Actions per Rule** | No | Yes | | **Create New Records** | No | Yes | | **Call Apex Code** | No | Yes | | **Scheduled Actions** | Yes | Yes | | **Future Support** | Being phased out | Being phased out (Use Flow instead) | #### **Key Takeaways** - **Workflow Rules are becoming obsolete**—Salesforce recommends **Flow for all new automation**. - **If a requirement only needs a field update, email, or task assignment**, Workflow Rules might still work. - **If multiple actions are needed or logic is complex, Flow is the preferred choice**. ### **2. Best Practices: Process Builder vs. Flow** Salesforce is **deprecating Process Builder** in favor of **Flow** because Flow is **more powerful and scalable**. #### **When to Use Flow?** **If the process requires multiple steps or decisions** → **Use Flow** **If the process needs to interact with multiple objects** → **Use Flow** **If user input is required (e.g., a guided screen flow)** → **Use Flow** **If automation needs to be migrated from Workflow or Process Builder** → **Use Flow** #### **When to Use Apex?** **If the process requires complex calculations or loops** → **Use Apex** **If the process requires external API calls (HTTP Callouts)** → **Use Apex** **If the automation needs to run asynchronously (background jobs)** → **Use Apex** | Scenario | Use Flow? | Use Apex? | | --- | --- | --- | | Simple field update | Yes | No | | Create or update related records | Yes | No | | Work across multiple objects | Yes | No | | Perform external API calls | No | Yes | | High-performance batch processing | No | Yes | #### **Key Takeaways** - **New automation should always be built with Flow instead of Process Builder**. - **Flow is declarative and easier to maintain, while Apex is for complex scenarios**. - **If Flow can handle a use case, avoid using Apex** (recommended by Salesforce). ### **3. Trigger Framework (Best Practices for Apex Triggers)** A **Trigger Framework** is a best practice for **managing triggers in large applications**. #### **Why use a Trigger Framework?** - **Prevents recursion issues** (multiple triggers on the same object can cause infinite loops). - **Separates business logic from the trigger**, making it **modular and reusable**. - **Ensures a single trigger per object**, improving maintainability. #### **Example: Using a Trigger Handler Class** **Trigger Code (Minimal Logic)** ```apex trigger AccountTrigger on Account (before insert, after update) { AccountTriggerHandler.handleTrigger(Trigger.new, Trigger.oldMap); } ``` **Handler Class (Encapsulated Logic)** ```apex public class AccountTriggerHandler { public static void handleTrigger(List newRecords, Map oldRecords) { for (Account acc : newRecords) { acc.Description = 'Handled by Trigger Framework'; } } } ``` #### **How to Prevent Recursive Trigger Execution?** - **Use static variables** to **track execution state**. - Example: ```apex public class PreventRecursion { private static Boolean isTriggerRunning = false; public static void executeTriggerLogic() { if (isTriggerRunning) return; isTriggerRunning = true; // Trigger logic here... isTriggerRunning = false; } } ``` #### **Key Takeaways** - **Use a single trigger per object and delegate logic to a handler class.** - **Prevent recursion using static variables.** - **Improve maintainability by keeping business logic out of triggers.** ### **4. Flow vs. Apex – When to Use Each?** **Flow is a declarative tool, while Apex provides advanced control over logic.** Choosing between them depends on complexity and performance needs. | Scenario | Use Flow? | Use Apex? | | --- | --- | --- | | Simple record updates | Yes | No | | Automate approvals | Yes | No | | Perform API callouts | No | Yes | | Perform bulk processing (batch jobs) | No | Yes | | Work with complex data structures | No | Yes | #### **Best Practice** - **If Flow can accomplish the task, use Flow instead of Apex.** - **Use Apex only for tasks that Flow cannot handle efficiently, such as complex calculations or API integrations.** ### **5. Asynchronous Apex – Choosing the Right Approach** Salesforce provides **four main asynchronous execution methods**: `@future`, `Queueable`, `Batch Apex`, and `Scheduled Apex`. #### **Comparison Table: Asynchronous Apex Methods** | Method | Use Case | Supports Chaining? | Supports Complex Objects? | | --- | --- | --- | --- | | `@future` | Lightweight, short-lived async jobs (e.g., API callouts) | No | No | | `Queueable` | Similar to `@future`, but supports chaining and complex objects | Yes | Yes | | `Batch Apex` | Process large datasets (e.g., bulk updates) | Yes | No | | `Scheduled` | Run jobs at specific times (e.g., nightly cleanups) | Yes | No | #### **Examples** **Using `@future` for API Callouts** ```apex public class AsyncExample { @future(callout=true) public static void callExternalAPI() { Http http = new Http(); HttpRequest request = new HttpRequest(); request.setEndpoint('https://example.com/api'); request.setMethod('GET'); HttpResponse response = http.send(request); } } ``` **Using `Queueable` for Complex Async Processing** ```apex public class QueueableExample implements Queueable { public void execute(QueueableContext context) { System.debug('Executing Queueable Job...'); } } System.enqueueJob(new QueueableExample()); ``` **Using `Batch Apex` for Large Data Processing** ```apex global class BatchExample implements Database.Batchable { global Database.QueryLocator start(Database.BatchableContext bc) { return Database.getQueryLocator('SELECT Id FROM Account'); } global void execute(Database.BatchableContext bc, List scope) { for (Account acc : scope) { acc.Name += ' - Updated'; } update scope; } } Database.executeBatch(new BatchExample()); ``` #### **Key Takeaways** - **For simple async tasks → Use `@future` (but limited functionality).** - **For complex objects and chaining → Use `Queueable` Apex.** - **For large-scale processing → Use `Batch Apex`.** - **For scheduled tasks → Use `Scheduled Apex`.** --- # User Interface (Additional Content) ### **1. Lightning Components (Aura Components)** Although **Lightning Web Components (LWC)** are the modern standard for Salesforce development, **Aura Components** (introduced in 2014) are still supported and used in specific use cases, such as **Experience Cloud (Community) pages and legacy Lightning components**. #### **1.1 What are Aura Components?** - Aura Components were the original **component-based framework** in Salesforce before LWC. - Unlike LWC, Aura uses a **Salesforce-specific framework** rather than standard web technologies. - They consist of multiple files (`.cmp`, `.controller`, `.helper`) for defining structure, logic, and helper functions. - Still widely used in **Experience Cloud** and **Lightning pages that have not yet been migrated to LWC**. #### **1.2 Aura Components vs. Lightning Web Components (LWC)** | Feature | Aura Components | Lightning Web Components (LWC) | | --- | --- | --- | | **Performance** | Slower due to framework overhead | Faster due to native browser support | | **Technology Base** | Salesforce-specific framework | Standard web technologies (HTML, JS, CSS) | | **Code Complexity** | Requires multiple files: `.cmp`, `.controller`, `.helper` | More streamlined code in a single JS module | | **Data Access** | Requires `@AuraEnabled` methods in Apex | Uses `@wire` and **Lightning Data Service (LDS)** | | **Future Development** | **No longer recommended for new projects** | **Preferred for all new development** | #### **1.3 Why is LWC Recommended Over Aura?** - **LWC is built using standard web technologies (HTML, JavaScript, CSS), making it faster and more scalable.** - **LWC is more efficient, reducing the need for Apex calls thanks to built-in Lightning Data Service (LDS).** - **LWC improves performance** due to its smaller footprint and optimized rendering. ##### **Possible Exam Question** *"Why does Salesforce recommend using LWC instead of Aura Components?"* - **Answer:** LWC is **faster, built on modern web standards, and optimized for scalability.** ### **2. Standard Controllers in Visualforce** Your existing **Visualforce** explanation is good, but it lacks details about **Standard Controllers**, which are often tested in the exam. #### **2.1 What is a Standard Controller?** - A **Standard Controller** allows Visualforce pages to use **existing Salesforce object data and built-in logic** **without requiring custom Apex code**. - Provides CRUD operations **automatically** for standard and custom objects. #### **2.2 Example of a Standard Controller in Visualforce** The following **Visualforce page** displays an `Account` record **without requiring an Apex controller**: ```html

{!Account.Name}

``` - **`standardController="Account"`** binds the page to the Account object. - **`{!Account.Name}`** dynamically retrieves the account’s name. - **``** renders a standard record detail view. #### **2.3 When to Use a Standard Controller vs. a Custom Controller?** | **Use Case** | **Standard Controller** | **Custom Controller** | | --- | --- | --- | | **Read and display object data** | Yes | Yes | | **Use built-in Salesforce logic** | Yes | No | | **Execute custom logic and SOQL queries** | No | Yes | | **Handle complex user interactions** | No | Yes | ##### **Possible Exam Question** *"When should you use a Standard Controller instead of a Custom Controller?"* - **Answer:** Use a **Standard Controller when you only need to retrieve and display object data without custom logic**. ### **3. Lightning Record Pages & App Builder** Your explanation of **Dynamic Forms** is great, but it lacks details on **Lightning Record Pages and Lightning App Builder**, which are commonly tested topics. #### **3.1 What are Lightning Record Pages?** - **Lightning Record Pages allow developers to customize Salesforce page layouts** using a **drag-and-drop interface**. - Can be created and modified using **Lightning App Builder**. - Supports adding components like **LWC, Aura, Standard Components, and Custom Visualforce Pages**. #### **3.2 What is Lightning App Builder?** - A **declarative tool** that allows users to create and customize Lightning pages **without coding**. - Used for **placing Lightning Web Components (LWC), Aura Components, and Standard Components**. - Accessible via **Setup > User Interface > Lightning App Builder**. #### **3.3 How to Add an LWC to a Lightning Page?** 1. **Navigate to Setup > Lightning App Builder.** 2. **Create or Edit a Lightning Page.** 3. **Drag and drop an LWC component onto the page layout.** 4. **Configure properties (if needed).** 5. **Save and Activate the page for users.** ##### **Possible Exam Question** *"How can you add an LWC to a Lightning Page?"* - **Answer:** Use **Lightning App Builder** to drag and drop an LWC component onto the page layout. ### **4. LWC Data Access: @wire and Apex Calls** Your **LWC explanation** is good, but it is missing **data access methods**, particularly `@wire` and Apex calls. #### **4.1 How Does LWC Retrieve Data?** LWC can retrieve Salesforce data in three ways: 1. **Lightning Data Service (LDS)** – Uses `lightning-record-form` and `lightning-record-view-form` (no Apex needed). 2. **@wire (Reactive Data Binding)** – Fetches data reactively from an Apex method. 3. **Imperative Apex Calls (Manual Execution)** – Calls Apex **on user action (e.g., button click)**. #### **4.2 Example: Using `@wire` to Query Account Data** ```javascript import { LightningElement, wire } from 'lwc'; import getAccounts from '@salesforce/apex/AccountController.getAccounts'; export default class AccountList extends LightningElement { @wire(getAccounts) accounts; } ``` - **`@wire(getAccounts) accounts;`** – Reactively fetches accounts from an Apex method. - **This method automatically re-fetches data if the record is updated.** #### **4.3 Example: Imperative Apex Call (User Action Required)** ```javascript import { LightningElement, track } from 'lwc'; import getAccounts from '@salesforce/apex/AccountController.getAccounts'; export default class AccountList extends LightningElement { @track accounts = []; handleLoadAccounts() { getAccounts() .then(result => { this.accounts = result; }) .catch(error => { console.error(error); }); } } ``` - **Imperative Apex calls are useful when the data should load only when triggered (e.g., by a button click).** ##### **Possible Exam Question** *"What is the best way to retrieve Apex data in LWC?"* - **Answer:** Use `@wire` for **reactive data binding** or **Imperative Apex Calls for user-triggered fetches**. --- # Testing, Debugging, and Deployment (Additional Content) ### **1. @TestSetup Annotation** #### **1.1 What is @TestSetup?** - `@TestSetup` is a special annotation in Apex testing that **creates reusable test data for multiple test methods** within the same test class. - It improves test efficiency by **reducing redundant data creation** and **ensuring consistent test conditions**. #### **1.2 Why Use @TestSetup?** - **Avoid duplicate test data creation** across test methods. - **Enhance test execution speed** by setting up shared data only once. - **Ensure consistency** across test cases, reducing the risk of variations due to data inconsistencies. #### **1.3 Example: Using @TestSetup** ```apex @isTest public class AccountTest { @TestSetup static void setupTestData() { Account acc = new Account(Name = 'Test Account'); insert acc; } @isTest static void testAccountTrigger() { Account insertedAcc = [SELECT Description FROM Account WHERE Name = 'Test Account']; System.assertEquals('Auto-generated Description', insertedAcc.Description); } } ``` ##### **Possible Exam Question** *"Why should you use `@TestSetup` in a test class?"* - **Answer:** To **avoid redundant data creation, speed up test execution, and ensure consistency across multiple test methods.** ### **2. Test.startTest() and Test.stopTest()** #### **2.1 Why Use Test.startTest() and Test.stopTest()?** - **Test.startTest() resets governor limits**, providing a **fresh execution context** to simulate real-world concurrent transactions. - **Test.stopTest() ends the test execution block**, ensuring that **asynchronous processes like Future, Queueable, and Batch Apex execute properly.** - Useful for **stress-testing Apex code within governor limits**. #### **2.2 Example: Testing Asynchronous Apex (Future Method)** ```apex @isTest public class AsyncTest { @isTest static void testFutureMethod() { Test.startTest(); FutureClass.someFutureMethod(); Test.stopTest(); System.assertEquals(1, [SELECT COUNT() FROM Async_Result__c]); } } ``` ##### **Possible Exam Question** *"What is the purpose of `Test.startTest()` and `Test.stopTest()` in a test class?"* - **Answer:** `Test.startTest()` **resets governor limits and provides a fresh execution context**, while `Test.stopTest()` **ensures that asynchronous operations execute before assertions.** ### **3. Debug Log Filtering** Your debugging explanation covers **System.debug()**, but **filtering logs in Developer Console** is crucial for analyzing large logs effectively. #### **3.1 How to Filter Debug Logs for System.debug()?** 1. **Open Developer Console.** 2. **Go to Debug > View Logs.** 3. **Set the Log Level to "Debug".** 4. **Select "Debug Only" to filter out unnecessary logs.** #### **3.2 Example: Using Log Filters** ```apex System.debug('Processing Account: ' + acc.Id); // Only shows debug-level logs ``` ##### **Possible Exam Question** *"How can you filter logs in Developer Console to show only `System.debug()` messages?"* - **Answer:** Use the **"Debug Only" filter in Developer Console** to display only debug-level logs. ### **4. Salesforce CLI (SFDX) Deployment** Salesforce DX (SFDX) is a command-line interface for managing **metadata deployment and version control**. #### **Common SFDX Commands for Deployment** ##### **Authenticate to Salesforce** ```sh sfdx force:auth:web:login -r https://login.salesforce.com ``` ##### **Deploy Local Metadata to an Org** ```sh sfdx force:source:push -u MyDevOrg ``` ##### **Retrieve Latest Changes from Salesforce** ```sh sfdx force:source:pull -u MyDevOrg ``` ##### **Retrieve Specific Metadata (Apex Classes, Objects, etc.)** ```sh sfdx force:source:retrieve -m ApexClass ``` ##### **Deploy a Specific Apex Class** ```sh sfdx force:source:deploy -m ApexClass:MyClass ``` ##### **Check Deployment Status** ```sh sfdx force:mdapi:deploy:report -u MyDevOrg ``` ##### **Run Apex Tests from CLI** ```sh sfdx force:apex:test:run -u MyDevOrg -r human ``` ##### **Delete Scratch Org After Testing** ```sh sfdx force:org:delete -u MyScratchOrg ``` ##### **Possible Exam Question** *"What SFDX command is used to deploy local metadata to Salesforce?"* - **Answer:** `sfdx force:source:push -u MyDevOrg` ### **5. Deployment Pipeline (CI/CD)** #### **5.1 What is CI/CD in Salesforce?** - **CI/CD (Continuous Integration & Deployment)** automates: - **Version control (e.g., GitHub, Bitbucket)** - **Automated testing** - **Automated deployments to different Salesforce environments** - This ensures **consistent, error-free deployments** across development teams. #### **5.2 Common CI/CD Tools for Salesforce** | **Tool** | **Functionality** | | --- | --- | | **GitHub Actions** | Automates deployments with version control | | **Jenkins** | Customizable automation for deployments | | **Bitbucket Pipelines** | CI/CD workflows for Git-based repositories | | **Azure DevOps** | Integrated CI/CD for large-scale enterprise use | #### **5.3 Example: Automating Salesforce Deployment with GitHub Actions** ```yaml name: Deploy to Salesforce on: push jobs: deploy: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v2 - name: Deploy to Salesforce run: sfdx force:source:deploy -p force-app -u MyDevOrg ``` - **Whenever code is pushed to the repository,** this action automatically **deploys updates to Salesforce.** ##### **Possible Exam Question** *"What is CI/CD in Salesforce development?"* - **Answer:** CI/CD automates **testing and deployment processes** using tools like GitHub Actions, Jenkins, and Azure DevOps. ---

Shopping cart

Subtotal:

Examination Introduction

Learning Method

Study Plan

Exam Center