Faculty of: FCE Program: [Link]. VI Sem.

Class/Section: AIDS Sec A, CE Sec G & H

Name of Faculty: Dr. Ravi Soni Name of Course: Salesforce Code: BCECCE6103

UNIT 2
Salesforce Configuration and Customization
1. Customizing Salesforce Layouts, Fields, and Page Layouts
Configuration and customization form the core strength of . Unlike traditional software systems that require
programming for every change, Salesforce allows most business requirements to be addressed through structured
configuration tools. These tools enable administrators to adapt the system to organizational processes while preserving
system stability, security, and scalability.
Customizing layouts, fields, and page layouts is the first and most fundamental step in this process. It directly affects
how data is captured, how users interact with records, and how information flows across departments.

1.1 Meaning of Configuration in Salesforce

Configuration in Salesforce refers to modifying system behavior and structure using built-in administrative tools rather
than writing program code. Configuration is declarative in nature, meaning changes are made by selecting options,
defining rules, and arranging components through the interface.
This approach exists because most organizational requirements are structural rather than algorithmic. Organizations
need to decide what data to store, how it should appear, and who should access it. Configuration addresses these needs
without introducing technical complexity.
Examples of configuration include:
• Adding new fields to store additional information
• Rearranging record pages for clarity
• Making certain fields mandatory
• Restricting visibility of sensitive information

1.2 Why Layout and Field Customization Is Necessary

Every organization operates differently. Even within the same industry, workflows, terminology, and priorities vary
significantly. A generic software layout cannot effectively support all these variations.
If users are presented with irrelevant fields or poorly organized screens:
• Data entry becomes slow and error-prone
• Important information is overlooked
• User adoption decreases
• Reports become unreliable
Customization ensures that the system reflects how the organization actually works, not how a software vendor
assumes it works.

1.3 Understanding Fields in Salesforce

A field is the smallest unit of data storage in Salesforce. Each field stores a single piece of information about a record.
Examples include:
• Customer Name
• Email Address
• Phone Number
• Order Value
• Registration Date
Every field has a data type, which defines:
Page 1 of 31
Faculty of: FCE Program: [Link]. VI Sem. Class/Section: AIDS Sec A, CE Sec G & H
Name of Faculty: Dr. Ravi Soni Name of Course: Salesforce Code: BCECCE6103

• What kind of data can be stored

• How the data is displayed
• How the data can be validated or used in automation
Common data types include text, number, currency, date, checkbox, and picklist.
Fields exist to enforce structure. Without fields, data would be unorganized and inconsistent, making automation and
reporting impossible.

1.4 Standard Fields and Custom Fields

Salesforce provides standard fields by default. These fields cover common business needs and are shared across all
organizations using the platform.
However, standard fields cannot represent every real-world requirement. This is where custom fields are used.
A custom field is created by an administrator to store organization-specific data. Custom fields behave exactly like
standard fields in terms of reporting, validation, and automation.
For example:
• A hospital may add a Blood Group field
• A university may add an Enrollment Number field
• A manufacturing firm may add a Machine Serial Number field
Custom fields allow Salesforce to model real organizational data accurately.

1.5 Process of Creating a Custom Field

Creating a custom field follows a defined and controlled process:
1. Select the object where the field is required
2. Choose an appropriate data type
3. Define the field label and internal name
4. Set field-level security
5. Add the field to relevant page layouts
Each step serves a purpose. Field-level security ensures that sensitive information is not exposed to unauthorized users.
Adding the field to page layouts ensures that users can actually see and use it.
A field that exists but is not placed on a page layout remains invisible to users.

1.6 Importance of Field-Level Security

Field-level security controls who can view or edit a field. This is separate from page layout visibility.
For example:
• Salary fields may be visible only to managers
• Internal notes may be hidden from external users
• Audit fields may be read-only for most roles
This layered control ensures data confidentiality without duplicating objects or records.

1.7 What Is a Page Layout

A page layout defines how a record page is structured for users. It determines:
• Which fields appear on the page
• The order and grouping of fields
• Which fields are required
Page 2 of 31
Faculty of: FCE Program: [Link]. VI Sem. Class/Section: AIDS Sec A, CE Sec G & H
Name of Faculty: Dr. Ravi Soni Name of Course: Salesforce Code: BCECCE6103

• Which buttons are available

• Which related lists are shown
Page layouts control presentation, not data storage. The same data can appear differently to different users based on
their role.

1.8 Structure of a Record Page

A typical record page is divided into logical sections:
• A highlights section showing key information
• Detailed sections grouping related fields
• Related lists showing connected records
• Activity and history sections
This structured design allows users to understand context without navigating multiple screens.

1.9 Customizing Page Layouts

Customizing a page layout involves arranging fields into meaningful sections. Fields that are frequently used are placed
at the top, while less important fields are grouped lower.
Administrators can:
• Create multiple page layouts for the same object
• Assign different layouts to different user profiles
• Control which actions users can perform
For example, a sales executive may see pricing and deal information, while a support executive sees service history and
issue details.

1.10 Role-Based Page Layouts

One of the strongest features of Salesforce is role-based interface customization. The same record can appear differently
to different users without duplicating data.
This approach:
• Improves usability
• Reduces errors
• Enhances security
• Aligns screens with job responsibilities
Role-based layouts ensure that users focus only on information relevant to their work.

1.11 Required and Read-Only Fields

Page layouts allow administrators to mark fields as required or read-only.
Required fields ensure that critical data is always captured. Read-only fields prevent unauthorized modification of
important information such as system-generated values or approved data.
These controls guide user behavior through interface design rather than strict technical enforcement.

1.12 Real-World Scenario: Educational Institution

Consider an educational institution managing student inquiries.
Important fields may include:
• Course Interest
Page 3 of 31
Faculty of: FCE Program: [Link]. VI Sem. Class/Section: AIDS Sec A, CE Sec G & H
Name of Faculty: Dr. Ravi Soni Name of Course: Salesforce Code: BCECCE6103

• Admission Status
• Counseling Officer
• Enrollment Date
By customizing the page layout:
• Admission staff see counseling and enrollment fields
• Faculty see academic details
• Management sees summary information
All users work with the same data, but through interfaces tailored to their role.

1.13 Relationship Between Fields, Page Layouts, and Data Quality

Well-designed layouts directly influence data quality. When fields are clearly labeled, logically grouped, and properly
restricted:
• Users enter accurate data
• Reports become reliable
• Automation works correctly
Poor layout design leads to incomplete records, inconsistent values, and reduced trust in the system.

1.14 Layout Customization as a Foundation for Automation

Automation tools such as validation rules, workflows, and processes depend on data stored in fields. If fields are poorly
defined or inconsistently used, automation fails.
Therefore, layout and field customization is not merely cosmetic. It is a foundational activity that supports advanced
Salesforce functionality.

1.15 Conceptual Summary

Customizing layouts, fields, and page layouts allows Salesforce to mirror real organizational processes. Fields define
what data is stored, page layouts define how data is presented, and customization ensures clarity, accuracy, and role-
based access.
This configuration-driven approach enables organizations to evolve their systems as business needs change, without
rewriting software or disrupting users.

Page 4 of 31
Faculty of: FCE Program: [Link]. VI Sem. Class/Section: AIDS Sec A, CE Sec G & H
Name of Faculty: Dr. Ravi Soni Name of Course: Salesforce Code: BCECCE6103

Salesforce Configuration and Customization

2. Creating Custom Objects and Relationships

Custom objects and relationships extend Salesforce beyond standard functionality and allow the platform to represent
organization-specific data models. While standard objects support common business needs, they cannot cover every
process followed by universities, hospitals, manufacturing units, government offices, or service organizations. Custom
objects and relationships exist to bridge this gap in a structured and scalable manner.
The concepts discussed in this section apply to , where data modeling is performed using configuration tools rather than
traditional database programming.

2.1 Why Custom Objects Are Needed

Standard objects such as Account, Contact, and Opportunity are designed for general-purpose customer management.
However, many organizations deal with entities that are unique to their domain.
Examples include:
• A university managing internships, projects, and faculty assignments
• A hospital tracking medical equipment and patient visits
• A manufacturing company monitoring assets and maintenance schedules
Attempting to store such information inside standard objects leads to confusion, misuse of fields, and unreliable
reporting. Custom objects exist to represent these real-world entities accurately.

2.2 Meaning of a Custom Object

A custom object is a user-defined data structure created to store information that is not available in standard objects.
Conceptually, a custom object is similar to a table in a database.
Each custom object:
• Stores a specific category of information
• Contains custom fields defined by the organization
• Supports relationships with other objects
• Appears in the Salesforce user interface like standard objects
Custom objects are identifiable by a suffix, but functionally they behave like built-in objects.

2.3 Characteristics of Custom Objects

Custom objects share several important characteristics:
• They can store records just like standard objects
• They support page layouts, validation rules, and automation
• They can participate in reports and dashboards
• They can be secured using permissions and profiles
This design ensures consistency across the platform. Users do not need to learn a new interface for custom data.

2.4 Examples of Custom Objects in Practice

Consider a university placement cell. Apart from students and companies, the institution may need to manage:
• Internship records
• Placement drives
• Company visits
Page 5 of 31
Faculty of: FCE Program: [Link]. VI Sem. Class/Section: AIDS Sec A, CE Sec G & H
Name of Faculty: Dr. Ravi Soni Name of Course: Salesforce Code: BCECCE6103

• Student applications
Each of these can be represented as a separate custom object. This allows structured storage of data instead of mixing
unrelated information inside standard objects.

2.5 Creating a Custom Object

Creating a custom object follows a defined process:
1. Define the object label and name
2. Decide record naming format
3. Enable features such as reports and activities
4. Save the object definition
5. Add custom fields
6. Design page layouts
The object definition establishes the identity of the data, while fields and layouts determine how the data is captured and
displayed.

2.6 Record Naming and Object Identity

Every record must have a unique identifier. Salesforce allows two common approaches:
• Auto-generated numbers
• User-entered names
Auto-numbering is preferred when records are system-managed, such as application IDs or transaction numbers. User-
entered names are suitable when records have meaningful titles, such as project names.
Choosing the correct naming method improves clarity and reporting accuracy.

2.7 Fields Inside Custom Objects

A custom object without fields cannot store meaningful data. Fields define what information is captured for each record.
Common examples of fields in a custom object include:
• Status
• Date
• Assigned person
• Numeric values
• Descriptive text
Field design should reflect real-world attributes of the entity being modeled. Poorly designed fields lead to confusion
and inconsistent data entry.

2.8 Page Layouts for Custom Objects

Custom objects require page layouts just like standard objects. Page layouts determine:
• Which fields appear on the record page
• How fields are grouped into sections
• Which related lists are shown
Layouts should be designed based on user roles and workflow sequence. Frequently used fields should appear at the top
of the page.

2.9 Understanding Relationships in Salesforce

Page 6 of 31
Faculty of: FCE Program: [Link]. VI Sem. Class/Section: AIDS Sec A, CE Sec G & H
Name of Faculty: Dr. Ravi Soni Name of Course: Salesforce Code: BCECCE6103

Salesforce is designed to store connected data, not isolated records. A relationship defines how one object is linked to
another.
Relationships:
• Maintain data integrity
• Reduce duplication
• Enable meaningful reporting
• Display related information automatically
Without relationships, Salesforce would behave like disconnected spreadsheets.

2.10 Why Relationships Are Necessary

In real-world systems:
• One company has many employees
• One student may have multiple internships
• One order may contain multiple items
Relationships allow Salesforce to represent these structures accurately. They also allow users to view related information
without manual searching.

2.11 Types of Relationships in Salesforce

Salesforce primarily supports two relationship types:
• Lookup Relationship
• Master-Detail Relationship
Each type serves a different modeling purpose and enforces different levels of dependency between objects.

2.12 Lookup Relationship

A lookup relationship creates a flexible link between two objects.
Key characteristics:
• Parent and child records exist independently
• Deleting one record does not delete the other
• Security is managed separately
Lookup relationships are used when data dependency is low.
Example:
• A faculty member linked to a department
• A student linked to a college
This approach provides flexibility without enforcing strict control.

2.13 Master-Detail Relationship

A master-detail relationship creates a strong dependency between objects.
Key characteristics:
• Child record cannot exist without a parent
• Deleting the parent deletes all child records
• Ownership and security are inherited
This relationship is used when data is tightly connected.
Example:
Page 7 of 31
Faculty of: FCE Program: [Link]. VI Sem. Class/Section: AIDS Sec A, CE Sec G & H
Name of Faculty: Dr. Ravi Soni Name of Course: Salesforce Code: BCECCE6103

• Internship record linked to a student record

• Invoice record linked to an order record
Master-detail relationships enforce discipline and data consistency.

2.14 Choosing Between Lookup and Master-Detail

The choice of relationship depends on business rules.
Use a lookup relationship when:
• Records must exist independently
• Flexibility is required
• Ownership should be separate
Use a master-detail relationship when:
• Child data depends completely on parent data
• Deletion rules must be enforced
• Aggregated reporting is needed
Selecting the wrong relationship type can lead to reporting limitations and data loss risks.

2.15 How Relationships Appear in the User Interface

Relationships are visible directly on record pages through related lists.
For example:
• A student record shows related internship records
• A project record shows related task records
Users can navigate connected data without switching objects manually. This improves efficiency and understanding.

2.16 Real-World Scenario: Internship Management

Consider an internship management system:
• Student is a standard object
• Internship is a custom object
• Company is a standard object
Relationships allow Salesforce to show:
• Which internships belong to which student
• Which company offered the internship
• Internship duration and status
This interconnected structure reflects the real academic process.

2.17 Reporting and Relationships

Relationships enable advanced reporting. Reports can:
• Group data by parent records
• Summarize child record values
• Show hierarchical views
Without relationships, reporting would require manual data consolidation, reducing reliability.

2.18 Data Integrity Through Relationships

Relationships prevent data inconsistency by enforcing structure. They ensure that:
Page 8 of 31
Faculty of: FCE Program: [Link]. VI Sem. Class/Section: AIDS Sec A, CE Sec G & H
Name of Faculty: Dr. Ravi Soni Name of Course: Salesforce Code: BCECCE6103

• Records are not duplicated unnecessarily

• Context is preserved
• Deletions follow business rules
This is critical for automation, analytics, and integrations.

2.19 Conceptual Summary

Custom objects allow Salesforce to represent organization-specific entities, while relationships connect these entities
into a meaningful data model. Together, they form the structural foundation of the platform.
A clear understanding of custom objects and relationships is essential before configuring validation rules, workflows,
and automation, which depend entirely on this data structure.

Page 9 of 31
Faculty of: FCE Program: [Link]. VI Sem. Class/Section: AIDS Sec A, CE Sec G & H
Name of Faculty: Dr. Ravi Soni Name of Course: Salesforce Code: BCECCE6103

Salesforce Configuration and Customization

3. Configuring Validation Rules, Workflows, and Process Automation

Modern information systems are not limited to storing data. They are expected to guide users, enforce business rules,
and perform routine actions automatically. In , this responsibility is handled through configuration-based automation
tools. Validation rules, workflows, and process automation work together to ensure data accuracy, procedural discipline,
and operational efficiency.
This topic builds directly on fields, page layouts, custom objects, and relationships. Automation cannot function
correctly unless the underlying data model is clearly defined.

3.1 Why Automation Is Required in Business Systems

In manual systems, employees rely on memory, emails, and informal communication to follow procedures. As
organizations grow, this approach leads to inconsistency and errors.
Common problems include:
• Incomplete or incorrect data entry
• Missed follow-ups
• Delayed approvals
• Uneven application of business rules
Automation exists to reduce dependence on human memory and judgment for routine tasks. The system itself ensures
that rules are followed consistently.

3.2 Concept of Business Rules in Salesforce

A business rule is a condition that must be satisfied for a process to be valid. These rules are usually derived from
organizational policies.
Examples include:
• A discount above a certain limit requires approval
• A record cannot be saved without mandatory information
• A task must be assigned when a request is created
Salesforce enforces such rules using declarative tools rather than hard-coded logic.

3.3 Validation Rules: Purpose and Definition

A validation rule checks whether entered data meets defined conditions before allowing a record to be saved. Validation
rules prevent incorrect or incomplete data from entering the system.
Validation rules operate at the data entry stage. If the rule condition evaluates to true, the system blocks the save
operation and displays an error message.
This ensures that only valid data becomes part of the database.

3.4 Why Validation Rules Are Necessary

Page layouts can make fields required, but they cannot enforce logical conditions. Validation rules fill this gap.
For example:
• A closing date must be in the future
• A phone number must follow a specific format
• A status cannot change unless certain fields are filled
Page 10 of 31
Faculty of: FCE Program: [Link]. VI Sem. Class/Section: AIDS Sec A, CE Sec G & H
Name of Faculty: Dr. Ravi Soni Name of Course: Salesforce Code: BCECCE6103

Without validation rules, such conditions would rely on user discipline, which is unreliable at scale.

3.5 How Validation Rules Work Conceptually

A validation rule consists of three parts:
1. A logical condition
2. A trigger point, which is record save
3. An error message
When a user attempts to save a record, the system evaluates the condition. If the condition is met, the save is blocked
and feedback is provided.
Validation rules do not modify data. They only permit or deny data entry.

3.6 Example Scenario: Academic Registration

Consider a university registration system.
Rule:
• A student cannot be marked as “Registered” unless fees are paid.
If a user attempts to update the registration status without completing fee details, the validation rule prevents saving the
record. This ensures procedural compliance without manual checking.

3.7 Designing Effective Validation Rules

Validation rules must be:
• Clear in logic
• Specific in scope
• Accompanied by meaningful error messages
Poorly designed rules frustrate users and slow down work. Error messages should explain what is missing or incorrect,
not just state that an error occurred.

3.8 Limitations of Validation Rules

Validation rules:
• Do not perform actions
• Do not update records
• Do not send notifications
They only prevent invalid data from being saved. For automated actions, workflows and processes are required.

3.9 Introduction to Workflow Automation

A workflow is an automated sequence of actions triggered when specified conditions are met. Workflows act after a
record is saved, unlike validation rules which act before saving.
Workflow automation exists to reduce manual effort and ensure timely execution of routine tasks.

3.10 Purpose of Workflow Rules

Workflow rules automate predictable actions such as:
• Sending email notifications
• Updating field values
• Creating follow-up tasks
Page 11 of 31
Faculty of: FCE Program: [Link]. VI Sem. Class/Section: AIDS Sec A, CE Sec G & H
Name of Faculty: Dr. Ravi Soni Name of Course: Salesforce Code: BCECCE6103

• Sending outbound messages

These actions occur automatically when predefined criteria are satisfied.

3.11 How Workflow Rules Operate

A workflow rule consists of:
1. Evaluation criteria
2. Rule conditions
3. Automated actions
When a record meets the criteria, the associated actions are executed. This may happen immediately or after a time
delay.

3.12 Example Scenario: Placement Cell Workflow

In a placement system:
• When a student is marked as “Placed”
• The system sends an email confirmation
• A follow-up task is created for documentation
• A status field is updated automatically
This entire sequence occurs without manual intervention.

3.13 Time-Based Workflow Actions

Workflows can include time-based actions that execute after a defined delay.
Examples include:
• Reminder emails sent after three days
• Escalation tasks created if no response is received
• Status updates after a deadline passes
Time-based automation ensures that processes continue even if users forget to act.

3.14 Limitations of Workflow Rules

Workflow rules have structural limitations:
• Limited logical complexity
• Restricted number of actions
• Less flexibility for branching logic
As business processes become more complex, workflows alone may not be sufficient.

3.15 Introduction to Process Automation

Process automation extends workflow capabilities. It allows the system to handle multi-step processes with conditional
logic and multiple outcomes.
Process automation is designed for modeling real-world procedures rather than simple triggers.

3.16 Process Builder Concept

Process Builder allows administrators to define:
• Multiple conditions
• Different actions for different outcomes
Page 12 of 31
Faculty of: FCE Program: [Link]. VI Sem. Class/Section: AIDS Sec A, CE Sec G & H
Name of Faculty: Dr. Ravi Soni Name of Course: Salesforce Code: BCECCE6103

• Sequential logic
It behaves like a decision tree where each branch represents a possible business path.

3.17 Example Scenario: Approval Process

Consider a purchasing system:
• If purchase value is below a threshold, auto-approve
• If above the threshold, route to manager
• If extremely high, route to senior authority
Process automation allows this logic to be implemented declaratively.

3.18 Actions Performed by Processes

Processes can:
• Create or update records
• Send notifications
• Launch approvals
• Invoke flows
This flexibility allows processes to manage entire business lifecycles.

3.19 Comparing Validation Rules, Workflows, and Processes

Each tool serves a distinct role:
• Validation rules enforce data correctness
• Workflow rules automate simple actions
• Processes handle complex, branching logic
Using the wrong tool leads to fragile systems. Effective configuration uses each tool for its intended purpose.

3.20 Real-World Integrated Example

In a training institute:
• Validation rules ensure required data is entered
• Workflows send confirmations and reminders
• Processes manage approvals and escalations
Together, they create a self-regulating system.

3.21 Impact on Organizational Efficiency

Automation reduces:
• Manual effort
• Processing delays
• Human error
It increases:
• Consistency
• Accountability
• Transparency
Users focus on decision-making rather than repetitive tasks.

Page 13 of 31
Faculty of: FCE Program: [Link]. VI Sem. Class/Section: AIDS Sec A, CE Sec G & H
Name of Faculty: Dr. Ravi Soni Name of Course: Salesforce Code: BCECCE6103

3.22 Conceptual Summary

Validation rules, workflows, and process automation form the behavioral layer of Salesforce. They ensure that data is
correct, actions are timely, and processes follow defined paths.
A strong understanding of these tools is essential before moving to programmatic automation using Apex, where logic
is enforced through code rather than configuration.

Page 14 of 31
Faculty of: FCE Program: [Link]. VI Sem. Class/Section: AIDS Sec A, CE Sec G & H
Name of Faculty: Dr. Ravi Soni Name of Course: Salesforce Code: BCECCE6103

Salesforce Configuration and Customization

4. Introduction to Apex Triggers and Custom Development

As organizations mature in their use of Salesforce, business requirements often become more complex than what can be
handled using configuration alone. Validation rules, workflows, and process automation are powerful, but they operate
within defined limits. When requirements involve complex conditions, cross-record logic, or system-level control,
custom development becomes necessary.
In , this need is addressed through Apex, a proprietary programming language designed specifically for the Salesforce
platform. This section introduces Apex conceptually, with a primary focus on Apex triggers, their purpose, and their
role within the overall automation hierarchy.

4.1 Why Custom Development Is Required

Declarative tools are intentionally designed to be safe, simple, and user-friendly. However, this simplicity limits their
expressive power.
Situations where configuration alone is insufficient include:
• Enforcing rules across multiple related records
• Performing calculations involving large datasets
• Controlling transaction-level behavior
• Integrating deeply with external systems
• Handling complex conditional logic with multiple dependencies
Custom development exists to address such advanced requirements while still operating within the Salesforce security
and governance framework.

4.2 Meaning of Apex in Salesforce

Apex is an object-oriented, strongly typed programming language developed by Salesforce. It runs on the Salesforce
servers and executes within the platform’s controlled environment.
Apex is not a general-purpose language. It is designed specifically to:
• Work with Salesforce data
• Respect platform security rules
• Operate within strict performance limits
• Integrate seamlessly with declarative features
Apex allows developers to extend Salesforce behavior without breaking its core architecture.

4.3 Position of Apex in the Salesforce Automation Stack

Salesforce automation can be understood as a layered structure:
• Page layouts and validation rules control user input
• Workflow and process automation manage routine actions
• Apex handles advanced, system-level logic
Apex does not replace configuration. Instead, it complements it. Best practice is to use configuration wherever possible
and Apex only where necessary.

4.4 What Is an Apex Trigger

An Apex trigger is a piece of logic that executes automatically when a specific data operation occurs on a Salesforce
Page 15 of 31
Faculty of: FCE Program: [Link]. VI Sem. Class/Section: AIDS Sec A, CE Sec G & H
Name of Faculty: Dr. Ravi Soni Name of Course: Salesforce Code: BCECCE6103

object.
Triggers respond to events such as:
• Record creation
• Record update
• Record deletion
• Record restoration
Triggers operate at the database transaction level, meaning they execute as part of the save operation itself.

4.5 Why Triggers Exist

Triggers exist to enforce business rules that cannot be implemented using declarative tools.
For example:
• Updating related records automatically when a change occurs
• Preventing invalid data changes based on complex conditions
• Maintaining consistency across multiple objects
Triggers ensure that such logic is applied uniformly, regardless of how the data change is initiated.

4.6 Trigger Events and Execution Context

Triggers are associated with specific data events. These events occur during the lifecycle of a record operation.
Conceptually, trigger execution can be divided into:
• Before events, which occur prior to saving data
• After events, which occur after data is saved
This distinction allows developers to control whether logic modifies data before storage or reacts to data changes after
storage.

4.7 Conceptual Flow of Trigger Execution

When a user or system attempts to save a record:
1. Salesforce validates data
2. Before-trigger logic executes
3. Record is saved to the database
4. After-trigger logic executes
5. Related automation may follow
This tightly controlled sequence ensures data integrity and predictable behavior.

4.8 Triggers and Data Integrity

Triggers are often used to maintain data integrity across related objects.
For example:
• When a student record is updated, related internship records may need updates
• When an order status changes, inventory records may need adjustment
Such logic cannot be handled reliably through workflows alone, especially when multiple records are involved.

4.9 Difference Between Triggers and Workflows

Although both triggers and workflows respond to data changes, they differ fundamentally.
Workflows:
Page 16 of 31
Faculty of: FCE Program: [Link]. VI Sem. Class/Section: AIDS Sec A, CE Sec G & H
Name of Faculty: Dr. Ravi Soni Name of Course: Salesforce Code: BCECCE6103

• Are declarative
• Support limited actions
• Are easier to maintain
• Operate at a higher level
Triggers:
• Are programmatic
• Support complex logic
• Operate at a lower level
• Require careful design and testing
Triggers should be used only when workflows and processes cannot meet the requirement.

4.10 Real-World Scenario: Examination System

Consider an examination management system.
Requirement:
• When a student’s final marks are updated
• The system must recalculate grade
• Update academic standing
• Update cumulative performance records
Such multi-step, cross-object logic is best handled through triggers.

4.11 Bulk Data Processing and Triggers

Salesforce allows users to update multiple records at once, such as through data imports.
Triggers must be designed to handle bulk operations. This ensures that:
• Performance remains stable
• Platform limits are not exceeded
• Logic behaves consistently for single and multiple records
This requirement distinguishes Salesforce development from traditional programming.

4.12 Platform Limits and Governance

Salesforce enforces strict execution limits to ensure fair usage and system stability.
Triggers must operate within limits related to:
• Number of database operations
• CPU execution time
• Memory usage
These limits encourage efficient design and prevent system abuse.

4.13 Apex and Security Model

Apex automatically respects Salesforce security settings.
This means:
• Users cannot access data they are not permitted to see
• Field-level and object-level security is enforced
• Triggers run in a controlled execution context
This design prevents accidental data exposure.
Page 17 of 31
Faculty of: FCE Program: [Link]. VI Sem. Class/Section: AIDS Sec A, CE Sec G & H
Name of Faculty: Dr. Ravi Soni Name of Course: Salesforce Code: BCECCE6103

4.14 Custom Development Beyond Triggers

Apex is not limited to triggers. It supports:
• Custom business logic
• Data processing services
• Integration logic
• Backend automation
Triggers are often the entry point into Apex development, but they are part of a broader ecosystem.

4.15 Relationship Between Apex and Configuration

Well-designed Salesforce systems use both configuration and code.
Configuration defines:
• Data structure
• Basic rules
• User experience
Apex defines:
• Complex logic
• Advanced automation
• System-level behavior
This division ensures maintainability and scalability.

4.16 Risks of Overusing Triggers

Improper use of triggers can lead to:
• Difficult maintenance
• Unexpected behavior
• Performance issues
Therefore, triggers must be:
• Clearly documented
• Carefully tested
• Used only when justified
Declarative solutions should always be evaluated first.

4.17 Academic Perspective on Apex

From an academic standpoint, Apex introduces you to:
• Event-driven programming
• Transaction-based logic
• Platform-constrained development
• Enterprise software principles
Understanding Apex conceptually is important even for roles that do not involve full-time development.

4.18 Conceptual Summary

Apex triggers enable Salesforce to handle complex business logic that cannot be achieved through configuration alone.
They operate at the database transaction level and ensure data consistency, integrity, and advanced automation.
Page 18 of 31
Faculty of: FCE Program: [Link]. VI Sem. Class/Section: AIDS Sec A, CE Sec G & H
Name of Faculty: Dr. Ravi Soni Name of Course: Salesforce Code: BCECCE6103

Triggers represent the transition from declarative configuration to programmatic control. Mastery of this concept
prepares learners for advanced customization and integration scenarios.

Page 19 of 31
Faculty of: FCE Program: [Link]. VI Sem. Class/Section: AIDS Sec A, CE Sec G & H
Name of Faculty: Dr. Ravi Soni Name of Course: Salesforce Code: BCECCE6103

Apex Programming Language and Apex Triggers

4.19 Introduction to the Apex Programming Language

Apex is the programming language used for custom development on the Salesforce platform. While configuration tools
define structure and simple behavior, Apex is used when logic becomes too complex for declarative automation.
Apex is:
• Object-oriented in design
• Strongly typed, meaning every variable has a defined data type
• Executed on Salesforce servers
• Closely integrated with Salesforce data and security rules
Unlike general-purpose languages, Apex is written specifically to work with Salesforce objects, records, and
transactions.

4.20 Basic Concepts of Apex Programming

4.20.1 Apex as an Object-Oriented Language
Apex follows standard object-oriented principles:
• Classes group related logic
• Methods define actions
• Objects represent records in Salesforce
Salesforce objects such as Account, Contact, or custom objects are treated as data types in Apex.

4.21 Apex Syntax: Core Building Blocks

4.21.1 Variables and Data Types
Variables store values temporarily during execution.
Examples of common Apex data types:
• Integer for whole numbers
• Decimal for numeric values with precision
• String for text
• Boolean for true or false
• Date for calendar dates
Example:
Integer marks = 85;
String grade = 'A';
Boolean passed = true;
Each variable must be declared with a type. This prevents ambiguity and improves reliability.

4.21.2 Conditional Statements

Apex uses standard conditional logic.
Example:
if (marks >= 40) {
passed = true;
} else {
passed = false;
Page 20 of 31
Faculty of: FCE Program: [Link]. VI Sem. Class/Section: AIDS Sec A, CE Sec G & H
Name of Faculty: Dr. Ravi Soni Name of Course: Salesforce Code: BCECCE6103

}
This structure allows Apex to apply business rules dynamically.

4.21.3 Loops
Loops are used when working with multiple records.
Example:
for (Integer i = 0; i < 5; i++) {
[Link](i);
}
In Salesforce, loops are most often used to process lists of records.

4.22 Working with Salesforce Data in Apex

Apex works directly with Salesforce objects.
Example:
Account acc = new Account();
[Link] = 'ABC Technologies';
insert acc;
This code:
1. Creates an Account object
2. Assigns a value to a field
3. Saves the record to the database
Apex respects object permissions and field-level security automatically.

4.23 What Is an Apex Trigger (Revisited)

An Apex trigger is a special Apex program that executes automatically when a record is inserted, updated, deleted, or
restored.
Triggers run as part of the database transaction. They do not require manual execution.
Triggers can run:
• Before saving data
• After saving data

4.24 Trigger Syntax and Structure

A trigger follows a fixed syntax.
General form:
trigger TriggerName on ObjectName (events) {
// logic
}
Example events:
• before insert
• before update
• after insert
• after update
• before delete
Page 21 of 31
Faculty of: FCE Program: [Link]. VI Sem. Class/Section: AIDS Sec A, CE Sec G & H
Name of Faculty: Dr. Ravi Soni Name of Course: Salesforce Code: BCECCE6103

• after delete

4.25 Simple Working Example: Before Insert Trigger

Scenario:
Automatically set a default status when a record is created.
Object: Student__c (custom object)
trigger StudentDefaultStatus on Student__c (before insert) {
for (Student__c s : [Link]) {
if (s.Status__c == null) {
s.Status__c = 'New';
}
}
}
Explanation:
• [Link] contains all records being inserted
• The loop ensures bulk safety
• The field value is set before the record is saved
This example demonstrates:
• Trigger structure
• Use of loops
• Data modification in a before trigger

4.26 Simple Working Example: After Update Trigger

Scenario:
Recalculate a result when marks are updated.
trigger StudentResultCalculation on Student__c (after update) {
for (Student__c s : [Link]) {
if (s.Marks__c >= 40) {
s.Result__c = 'Pass';
} else {
s.Result__c = 'Fail';
}
}
update [Link];
}
Conceptual purpose:
• Reacts to data change
• Applies conditional logic
• Updates record after save
This example is useful for discussing post-save logic and data consistency.

4.27 Trigger Context Variables

Salesforce provides built-in variables inside triggers.
Page 22 of 31
Faculty of: FCE Program: [Link]. VI Sem. Class/Section: AIDS Sec A, CE Sec G & H
Name of Faculty: Dr. Ravi Soni Name of Course: Salesforce Code: BCECCE6103

Common ones include:

• [Link] – new versions of records
• [Link] – old versions of records
• [Link]
• [Link]
• [Link]
These variables allow a single trigger to respond intelligently to different events.

4.28 Rules and Best Practices for Apex Triggers

Triggers must follow strict design rules:
• Always support bulk operations
• Avoid hardcoding values
• Keep logic efficient
• Do not perform unnecessary database operations
• Prefer configuration before code
Triggers should enforce rules, not duplicate declarative automation.

4.29 Conceptual Difference Between Apex Code and Triggers

Aspect Apex Class Apex Trigger
Execution Manually invoked Automatic
Purpose Business logic Event response
Scope General logic Data lifecycle
Use case Calculations, services Data enforcement
Triggers are entry points. Apex classes usually hold reusable logic.

4.30 Academic Summary of Apex and Triggers

Apex introduces students to event-driven programming within a controlled enterprise platform. Triggers demonstrate
how systems respond automatically to data changes and enforce consistency at the transaction level.
Understanding Apex and triggers completes the transition from configuration-based automation to programmatic
control. This prepares learners for advanced customization, integration logic, and enterprise-scale system design.

Page 23 of 31
Faculty of: FCE Program: [Link]. VI Sem. Class/Section: AIDS Sec A, CE Sec G & H
Name of Faculty: Dr. Ravi Soni Name of Course: Salesforce Code: BCECCE6103

Salesforce Configuration and Customization

5. Integrating External Systems with Salesforce Using APIs

In modern organizations, no single software system works in isolation. Business operations typically involve multiple
applications such as websites, mobile apps, accounting systems, learning management systems, payment gateways, and
analytics platforms. For Salesforce to function as a central operational system, it must be able to exchange data with
these external systems in a controlled and reliable manner.
In Salesforce, this capability is provided through Application Programming Interfaces, commonly referred to as APIs.
This section explains the concept of integration, the role of APIs, and how Salesforce participates in interconnected
digital environments.

5.1 Why Integration Is Necessary

Organizations accumulate software systems over time. Each system is usually designed for a specific purpose.
For example:
• A website collects customer inquiries
• An ERP system manages billing and inventory
• A mobile app supports field staff
• An analytics tool processes performance data
If these systems do not communicate:
• Data must be entered manually multiple times
• Information becomes inconsistent
• Processes slow down
• Errors increase
Integration exists to ensure that data flows automatically and accurately between systems.

5.2 Meaning of System Integration

System integration is the process of connecting two or more software systems so that they can share data and trigger
actions across boundaries.
In practical terms, integration allows:
• One system to send data to another
• One system to request data from another
• Two systems to remain synchronized
Integration does not mean merging systems. Each system continues to perform its specialized role while exchanging
information as needed.

5.3 Role of Salesforce in an Integrated Environment

Salesforce often acts as:
• A central customer data repository
• A process coordination system
• A reporting and monitoring platform
Because of this role, Salesforce frequently needs to:
• Receive data from external sources
• Send updates to downstream systems
Page 24 of 31
Faculty of: FCE Program: [Link]. VI Sem. Class/Section: AIDS Sec A, CE Sec G & H
Name of Faculty: Dr. Ravi Soni Name of Course: Salesforce Code: BCECCE6103

• Respond to requests initiated outside the platform

APIs enable Salesforce to perform all these functions securely.

5.4 Understanding APIs Conceptually

An API is a defined interface that allows one software system to communicate with another using structured requests
and responses.
An API specifies:
• What data can be requested
• How requests should be formatted
• How responses are returned
• What security rules apply
APIs act as controlled entry points. External systems cannot directly access internal databases. They must use the API
as an intermediary.

5.5 Real-World Analogy for APIs

An API can be compared to a service counter in an organization.
A visitor:
• Cannot enter internal offices freely
• Submits a request at the counter
• Receives information or service through formal procedures
Similarly, an external system communicates with Salesforce only through APIs, following predefined rules.

5.6 Types of Integration Scenarios

Salesforce integration typically occurs in three common scenarios:
• Inbound integration, where Salesforce receives data
• Outbound integration, where Salesforce sends data
• Bidirectional integration, where both systems exchange updates
Each scenario serves a different business need and requires careful design.

5.7 Inbound Integration into Salesforce

Inbound integration occurs when external systems send data into Salesforce.
Examples include:
• Website forms creating lead records
• Mobile apps updating service requests
• External systems uploading transaction data
Inbound integration ensures that Salesforce always reflects the latest information collected elsewhere.

5.8 Outbound Integration from Salesforce

Outbound integration occurs when Salesforce sends data to external systems.
Examples include:
• Sending customer data to billing systems
• Updating ERP systems with order status
• Pushing data to analytics platforms
Page 25 of 31
Faculty of: FCE Program: [Link]. VI Sem. Class/Section: AIDS Sec A, CE Sec G & H
Name of Faculty: Dr. Ravi Soni Name of Course: Salesforce Code: BCECCE6103

Outbound integration ensures that other systems remain synchronized with Salesforce updates.

5.9 Bidirectional Integration

Bidirectional integration combines inbound and outbound communication.
In such cases:
• Changes in Salesforce update external systems
• Changes in external systems update Salesforce
This approach is common in enterprise environments but requires strict control to avoid data conflicts.

5.10 APIs Supported by Salesforce

Salesforce provides multiple API types to support different integration needs. These APIs differ in purpose, complexity,
and performance characteristics.
The most commonly used APIs include:
• REST-based APIs
• SOAP-based APIs
• Bulk data APIs
• Streaming and event-based APIs
Each API type is designed for a specific integration pattern.

5.11 REST APIs: Conceptual Overview

REST APIs are designed for lightweight, stateless communication over the internet.
They are widely used because:
• They are simple to consume
• They use standard web protocols
• They are suitable for mobile and web applications
REST APIs typically exchange data in a structured text format that is easy to process.

5.12 SOAP APIs: Conceptual Overview

SOAP APIs are designed for structured and formal communication.
They are often used when:
• Strict message formats are required
• Enterprise systems are involved
• Strong contracts between systems are necessary
SOAP APIs emphasize reliability and formal definitions over simplicity.

SOAP (Simple Object Access Protocol) is a

strict, standardized protocol, while REST (Representational State Transfer) is a flexible architectural style. The
choice between them depends on project requirements, with REST generally used for modern web services and SOAP
for enterprise-level systems requiring robust security and transaction integrity.
Core Differences
Feature
SOAP REST

Page 26 of 31
Faculty of: FCE Program: [Link]. VI Sem. Class/Section: AIDS Sec A, CE Sec G & H
Name of Faculty: Dr. Ravi Soni Name of Course: Salesforce Code: BCECCE6103

Design Model Protocol (strict rules) Architectural style (flexible guidelines)

Message Format XML only (verbose) JSON (most common), XML, HTML, plain text
Transport Protocol HTTP, SMTP, TCP, and more Primarily HTTP/HTTPS only
Interface Required (WSDL file) Optional (OpenAPI/Swagger used for
Definition documentation)
Performance Slower due to larger Faster and more lightweight
messages/overhead
Caching Not built-in/supported at HTTP level Built-in HTTP caching support
State Can be stateful or stateless Stateless by design

When to use SOAP vs. REST

Use Cases
Rationale
Use SOAP Enterprise-level applications, financial transactions, and healthcare systems where high security (WS-
for... Security), transaction reliability (ACID compliance), and formal contracts are paramount.
Use REST Modern web and mobile applications, public APIs, and microservices where simplicity, flexibility,
for... scalability, and performance (via JSON and caching) are key.

While both enable communication between systems, REST is generally the more popular choice for new development
due to its simplicity and lightweight nature, as seen with companies like Google and Amazon. SOAP, despite its
complexity, remains a critical tool for legacy systems and specific, high-assurance integrations.

5.13 Bulk Data Integration

Some integration scenarios involve large volumes of data.
Examples include:
• Initial data migration
• Periodic synchronization of records
• Batch updates from external systems
Bulk data APIs are optimized for handling such operations efficiently without overloading the system.

5.14 Event-Based and Streaming Integration

Event-based integration allows systems to react to changes in real time.
For example:
• A record update triggers an event
• Subscribed systems receive notifications
• Actions are performed immediately
This model supports responsive and scalable architectures.

5.15 Authentication and Security in API Integration

Integration must be secure. APIs enforce authentication to ensure that only authorized systems can communicate.
Security mechanisms typically control:
• Identity of the calling system

Page 27 of 31
Faculty of: FCE Program: [Link]. VI Sem. Class/Section: AIDS Sec A, CE Sec G & H
Name of Faculty: Dr. Ravi Soni Name of Course: Salesforce Code: BCECCE6103

• Scope of data access

• Rate of requests
This prevents unauthorized access and misuse of system resources.

5.16 Importance of Access Control

APIs respect the same security model used by Salesforce users.
This ensures that:
• External systems cannot access restricted data
• Field-level and object-level controls apply
• Integration follows organizational security policies
Security is not bypassed for integrations.

5.17 Error Handling in Integration

Integration processes must handle failures gracefully.
Common failure scenarios include:
• Network interruptions
• Invalid data formats
• Authorization errors
• System downtime
Well-designed integrations detect errors, log details, and retry operations where appropriate.

5.18 Real-World Scenario: University Admission System

Consider a university admission system.
Process:
• Students submit applications on a website
• Application data is sent to Salesforce
• Admission decisions are updated in Salesforce
• Results are sent back to the student portal
APIs enable this seamless exchange without manual intervention.

5.19 Integration and Data Consistency

Integration design must ensure data consistency.
Key considerations include:
• Identifying unique records
• Avoiding duplicate creation
• Resolving conflicts between systems
Poorly designed integration leads to fragmented and unreliable data.

5.20 Integration as Part of Digital Ecosystem

Salesforce integrations allow organizations to build a connected digital ecosystem.
Instead of isolated tools, organizations operate interconnected systems that:
• Share data
• Coordinate processes
Page 28 of 31
Faculty of: FCE Program: [Link]. VI Sem. Class/Section: AIDS Sec A, CE Sec G & H
Name of Faculty: Dr. Ravi Soni Name of Course: Salesforce Code: BCECCE6103

• Support real-time decision-making

Integration transforms Salesforce from a standalone application into an enterprise platform.

5.21 Academic Perspective on APIs

From an academic viewpoint, API integration introduces students to:
• Distributed systems
• Service-oriented architecture
• Secure communication
• Enterprise data flow
These concepts are central to modern software engineering beyond Salesforce.

5.22 Conceptual Summary

Integration using APIs allows Salesforce to communicate with external systems in a secure, structured, and scalable
manner. APIs define how data is exchanged, how systems remain synchronized, and how business processes extend
beyond platform boundaries.
Understanding API-based integration completes the study of Salesforce configuration and customization, connecting
internal data models and automation with the broader digital environment.

Page 29 of 31
Faculty of: FCE Program: [Link]. VI Sem. Class/Section: AIDS Sec A, CE Sec G & H
Name of Faculty: Dr. Ravi Soni Name of Course: Salesforce Code: BCECCE6103

UNIT 2 – Trailhead
Salesforce Configuration and Customization

Topic 1: Customizing Salesforce Layouts, Fields, and Page Layouts

Trailhead Module: Customize a Salesforce Object
What it Covers: This module explains how to add custom fields, modify page layouts, control field visibility, and
organize record pages. It directly supports understanding how user interfaces are shaped using configuration tools.
Trailhead Link: [Link]

Topic 2: Creating Custom Objects and Relationships

Trailhead Module: Data Modeling
What it Covers: This module focuses on creating custom objects, defining fields, and establishing relationships such
as lookup and master-detail. It aligns with conceptual data modeling taught in undergraduate courses.
Trailhead Link: [Link]

Topic 3: Configuring Validation Rules, Workflows, and Process Automation

Trailhead Module 1: Validation Rules
What it Covers: This module explains how Salesforce enforces business rules at the data entry level and prevents
invalid records from being saved.
Trailhead Link: [Link]
Trailhead Module 2: Workflow Automation
What it Covers: This module introduces workflow rules, automated actions, and time-based processes, forming the
foundation of declarative automation.
Trailhead Link: [Link]
Trailhead Module 3: Build Automated Processes
What it Covers: This module introduces process automation concepts for handling multi-step business logic beyond
basic workflows.
Trailhead Link: [Link]

Topic 4: Introduction to Apex Triggers and Custom Development

Trailhead Module: Apex Triggers
What it Covers: This module introduces the concept of event-driven programming in Salesforce. It explains when and
why triggers are used, without assuming prior programming experience.
Trailhead Link: [Link]
Supplementary Module (Optional): Apex Basics & Database
Trailhead Link: [Link]

Topic 5: Integrating External Systems with Salesforce Using APIs

Trailhead Module 1: API Basics
What it Covers: This module introduces APIs conceptually, explaining how Salesforce communicates with external
systems using structured requests and responses.
Trailhead Link: [Link]
Trailhead Module 2: Salesforce Integration Basics
Page 30 of 31
Faculty of: FCE Program: [Link]. VI Sem. Class/Section: AIDS Sec A, CE Sec G & H
Name of Faculty: Dr. Ravi Soni Name of Course: Salesforce Code: BCECCE6103

What it Covers: This module explains integration patterns, inbound and outbound data flow, and real-world system
connectivity scenarios.
Trailhead Link: [Link]

Page 31 of 31