0% found this document useful (0 votes)
7 views46 pages

Salesforce Notes-1

The document provides an overview of Salesforce architecture, including its components such as apps, instances, superpods, organizations, and sandboxes, along with the benefits of its multi-tenant architecture. It details the Apex programming language, its features, triggers, and integration patterns, emphasizing the importance of asynchronous operations and governor limits. Additionally, it compares Apex with Salesforce Flow, highlighting their respective use cases and limitations.

Uploaded by

aditis.dis
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
7 views46 pages

Salesforce Notes-1

The document provides an overview of Salesforce architecture, including its components such as apps, instances, superpods, organizations, and sandboxes, along with the benefits of its multi-tenant architecture. It details the Apex programming language, its features, triggers, and integration patterns, emphasizing the importance of asynchronous operations and governor limits. Additionally, it compares Apex with Salesforce Flow, highlighting their respective use cases and limitations.

Uploaded by

aditis.dis
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 46

Salesforce architecture is a series of layers sitting on top of each other.

 App: All metadata elements such as objects, Visualforce pages, classes, etc. are independent of an app. An app
simply helps you cluster things visually. However, internal metadata has nothing to do with the app, but you’ll be
able to have a similar tab, VF Page, etc. in multiple apps.
 Instance: An instance of Salesforce is the particular configuration that you see when you log in to Salesforce. A
Salesforce instance basically indicates server details for a particular Salesforce organization on which it lives. It is
possible for many Salesforce instances to live on one server. While an instance is created based on the location of
a user, it will be changed based on the region from where the user logs in.
 Superpod: Superpod is the arrangement of frameworks and stack balancers, including outbound intermediary
servers, system and capacity foundations, mail servers, SAN texture, and various other frameworks supporting
different instances.
 Org (organization): It is a single consumer of the Salesforce application. An org is incredibly adjustable and has
very clear security and sharing settings.
 Sandbox: Whenever a sandbox is created, Salesforce copies the metadata from your production org to the
sandbox org. By doing so, you can create multiple copies of your production org in separate environments.
 Multi-tenant architecture: Multitenancy is when
several different cloud customers are accessing the
same computing resources, such as when several
different companies are storing data on the same
physical server. It isolates and concurrently
supports the varying requirements of many
tenants.
 Advantage of multi-tenant architecture:
 It is cost-effective as the application is shared by
multiple clients.
 The development and maintenance costs of an
application is low.
 Application and Server Patching in one-go
 Efficient
METADATA
 The metadata means data about the data. Salesforce stores the metadata in
the shared database along with the data. It means it stores the data as well
as what data does.
 The tenant-specific data ensures that the common data is only shared with
one tenant, not with another tenant or group (as shown in figure). This
ensures the security of the data even in the shared database.

API
 The API provides a simple but powerful, and open way to programmatically
access the data and any app running on the salesforce platform.
 These APIs helps the developers to access apps from any location, using any
programming language that supports Web services, like Java, PHP, C#,
or .NET.
 Apex is a strongly typed, object-oriented programming language that allows developers to execute the flow and transaction
control statements on the Force.com platform server in conjunction with calls to the Force.com API.
 Apex has a Java-like syntax and acts like database stored procedures.

 It enables the developers to add business logic to most system events, including button clicks, related record updates, and
Visualforce pages.
 Apex code can be initiated by
 Web service requests
 Triggers on objects.

 Apex is included in Performance Edition, Unlimited Edition, Enterprise Edition, and Developer Edition.
 Integrated
Apex has built in support for DML operations like INSERT, UPDATE, DELETE and also DML Exception handling.
It has support for inline SOQL and SOSL query handling which returns the set of sObject records.

 Java like syntax and easy to use

 Strongly Integrated With Data


Apex is data focused and designed to execute multiple queries and DML statements together. It issues multiple transaction statements
on Database.

 Strongly Typed
Apex is a strongly typed language. It uses direct reference to schema objects like sObject and any invalid reference quickly fails if it is
deleted or if is of wrong data type.

 Multitenant Environment
Apex runs in a multitenant environment. Consequently, the Apex runtime engine is designed to guard closely against runaway code,
preventing it from monopolizing shared resources.
Any code that violates limits fails with easy-to-understand error messages.

 Easy Testing
Apex provides built-in support for unit test creation and execution, including test results that indicate how much code is covered, and
which parts of your code can be more efficient.
 It cannot show the elements in User Interface.

 You cannot change the standard SFDC provided functionality and also it is not possible to prevent the standard functionality
execution.
 Creating multiple threads is also not possible as we can do it in other languages.
 Create Web services with integrating other systems.

 Create email services for email blast or email setup.

 Perform complex validation over multiple objects at the same time and also custom validation implementation.

 Create complex business processes that are not supported by existing workflow functionality or flows.

 Create custom transactional logic (logic that occurs over the entire transaction, not just with a single record or object) like
using the Database methods for updating the records.
 Perform some logic when a record is modified or modify the related object's record when there is some event which has
caused the trigger to fire.
Working Structure of Apex
 Asynchronous operation means that a process
operates independently of other processes. It is
used to run process in a different thread. An
asynchronous process is a process that
executes a task “in the background” without
the user having to wait for the task to finish. It
help us to solve Governor Limits in Salesforce.
 Asynchronous Process on the Salesforce
Platform
 Ensure fairness of processing – Make sure
every customer gets a fair chance at
processing resources.
 Ensure transactional capabilities – Ensure
equipment or software failures allow
continued processing at reduced capacity
and requests are persisted until completion.
 Queue based framework
 Enqueue – The request gets put into the queue. This could be an Apex batch request, @future Apex request or one
of many others. The Salesforce application will enqueue requests along with the appropriate data to process that
request.
 Persistence – The enqueued request gets persisted. Requests are stored in persistent storage for failure recovery and
to provide transactional capabilities.
 Dequeue – The enqueued request is removed from the the queue and processed. Transaction management occurs in
this step to assure messages are not lost if there is a processing failure.
 Schedule & Batch jobs

 Queues

 @future

 Change Data Capture

 Platform Events – Event Based

 Continuations (UI)
Asynchronous Synchronous
Actions that will not block the transaction or
Quick and Immediate actions
Process
Duration is not priority Transactions are immediate and serial

Higher Governor limits Normal Governor Limits

Synchronous Programming
Synchronous programming in Apex executes tasks sequentially, one after the other, in the order they are
called. While simpler to understand, synchronous programming can lead to performance issues if tasks
take a long time to complete, as it blocks the main thread until execution finishes.
 Variable Declaration
Variables to be declared with data type in Apex. Example: lstAcc is declared with data type as List of Accounts.

 SOQL Query
This will be used to fetch the data from Salesforce database. The query shown in screenshot is fetching data from Account object.

 Loop Statement
This loop statement is used for iterating over a list or iterating over a piece of code for a specified number of times.

 Flow Control Statement


The If statement is used for flow control in this code. Based on certain condition, it is decided whether to go for execution or to stop the
execution of the particular piece of code.

 DML Statement
Performs the records insert, update, delete operation on the records in database. Example, the code given below helps in updating Accounts with new field value.
 List - List can contain any number of records of primitive, collections, sObjects, user defined
and built in Apex type. Always starts with 0. This is synonymous of Array in Java

Example:
List<string> ListOfCities = new List<string>(); System.debug('Value Of
ListOfCities'+ListOfCities);

 List of Accounts (sObject)


 Set
 Map
Sr.No. Loop Type & Description

1 for loop This loop performs a set of statements for each item in a set of records.

2 SOQL for loop Execute a sequence of statements directly over the returned set o SOQL query.

3 Java-like for loop Execute a sequence of statements in traditional Java-like syntax.

while loop Repeats a statement or group of statements while a given condition is true. It tests the condition before executing
4
the loop body.

5 do...while loop Like a while statement, except that it tests the condition at the end of the loop body.
WHAT IS APEX TRIGGERS?
Triggers in Salesforce are programmatic event handler that executes custom actions before or after specific
operations on Salesforce records. These operations can include the creation, update, or deletion of a record.
Triggers, written in Apex (Salesforce’s proprietary programming language), provide a powerful way to automate
complex business processes.

The triggers are apex codes that execute before or after specific operations, include;
• insert
• update
• delete
• merge
• upsert
• Undelete

• Syntax
Trigger <trigger name> on <object name> (trigger Events) { }

The usage of Trigger:

The primary use of triggers in Salesforce is to automate and manage complex business operations that can’t be
handled by Salesforce’s built-in point-and-click tools. Triggers can validate or modify field values before they’re
saved to the database, create or modify related records, perform complex calculations, enforce custom business
logic, or integrate with external systems.
 Trigger to be created in the sandbox or a developer edition org.
No matter what apex code you run there, it doesn’t affect your
live Salesforce database. Sandbox is very convenient for
developers.

 Steps to Create Trigger:


 Click the “Setup” icon.
 Right-click on the “Developer Console” and click “Open link
in New Tab.” This way, the developer console opens as a tab
in the browser window rather than a new window. This is
more convenient to work with.
 Click “File” -> “New” -> “Apex Trigger”
 Specify “Name” and select “Object.”
 Click “Submit.”
 Write Trigger Code
Trigger exceptions are the restrictions that you sometimes need in the database operation. Trigger exceptions are also
called Block Triggers.
For example, Triggers can be used to prevent the occurrence of DML operations by using the addError() method
on the field.
So when Triggers are used, custom error messages will be seen in the application interface. There is a minimum delay in
response time if errors are added before the Triggers.

Triggers vs. Workflow in Salesforce

• Triggers and Workflows are both


automation tools in Salesforce.
• Triggers are programmatic, and
Workflows are declarative in nature.
Trigger errors in Salesforce can be avoided by following some of the below practices:
Bulkify Your Code: Make sure your triggers are capable of handling multiple records at once. Without this, you may hit
governor limits when processing large sets of data.
Avoid Recursive Triggers: A recursive trigger is an event where the same trigger is fired repeatedly, leading to an infinite
loop. Create a static variable and check its value before any execution in the trigger to prevent this.
Exception Handling: Include exception-handling logic in your triggers to handle unexpected issues gracefully.
Proper Testing: Ensure to cover all scenarios, both expected and unexpected, during the testing phase. Salesforce
recommends at least 75% code coverage for the triggers.
 There are several limitations of triggers in Salesforce:

 Governor Limits: Salesforce enforces various limits on the number of database operations, the amount of CPU
time, and the memory capacity that triggers can use.
 Order of Execution: The order in which triggers are executed can’t be explicitly controlled.

 Testing and Deployment: Triggers must have at least 75% test coverage in order to be deployed to a production
environment.
 Recursive Triggers: Avoiding recursive triggers can be complex. If the same trigger is fired continuously, you may
run into infinite loops.
 Complexity: Triggers can become complex, especially as more business logic is added. This can lead to difficult-
to-maintain code.
Salesforce can’t be a source of everything. It can be CRM or any Custom application. However, SAP can own Order
Management or Inventory, an External system for sending emails, Other System for Payment, External Fleet Management, And
possibilities are high that Salesforce would need to exchange data with these systems.
 Maintain same transaction : Does Salesforce need to perform anything on response ?

 Synchronous vs Asynchronous : Is it business critical & response needs to be processed in real time or near real time ?

 Message size : Is it small or large ?

 Guaranteed delivery needed : What if external system is down ?

 Contract first integration possibility : Can remote system follow Salesforce Contract ?

 Declarative preferred : Do we want to integrate without writing any code in Salesforce ?


There are five types of integration patterns in Salesforce
 1. Request & Reply - Salesforce invokes a process on a remote system, waits for completion of that process, and
then tracks state based on the response from the remote system. The options we have for request & reply.
 External Services: Point & click based integration from Lightning Flow. External system should provide OpenAPI or
Inter agent schema. Only supports primitive datatypes
 LWC or Visualforce calling external system: Salesforce enables you to consume WSDL and generate proxy classes.
It also provides HTTP services using which we can perform GET, POST, PUT or Delete operations. A user can
initiate operation from custom UI.
 Trigger: We can make callout to external system on data change via trigger. However callout made must be
asynchronous. This solution is not recommended for request and reply but better suited for Fire and Forget.
 Batch Apex invoking external services: We can make callout to external system using Batch Apex. Execute
method in Batch apex gets refresh governor limit every time however there are governor limits on total callout or
time of callout in single transaction.
2. Fire & Forget
Salesforce invokes a process in a remote system but doesn’t wait for completion of the process. Instead, the remote process
receives and acknowledges the request and then hands off control back to Salesforce. This can achieve by:
 Process-driven platform events

 Customization-driven platform events

 Workflow-driven outbound message

 Apex based Callouts

3. Batch Data Synchronization


Data stored in Lightning Platform is created or refreshed to reflect updates from an external system, and when changes
from Lightning Platform are sent to an external system. Updates in either direction are done in a batch manner.
 Change Data Capture : Salesforce publishes change events, which represents changes on records

 Using ETL Tool : This tool connects to systems, extract data, transform in require target format and uploads using Bulk API
or SOAP API
 Manual Remote Calls : Salesforce or external system can call each other every time data is changed. However, it would
cause huge ongoing traffic and should be avoided if possible
4. Remote Call-In
Data stored in Lightning Platform is created, retrieved, updated, or deleted by a remote system.
 SOAP & Rest API

 Apex based APIs


5. Data Virtualization
Salesforce accesses external data in
real time. This removes the need to
persist data in Salesforce and then
reconcile the data between Salesforce
and the external system.
 Salesforce Flow provide option for users to automate simple processes without the need for coding
knowledge.
 Provides a user-friendly interface and can be easily customized using pre-built templates.

 Salesforce Flow allows users to easily update and adjust their workflows as needed.
Context Apex Salesforce flow

We need Salesforce Developer to write code in Salesforce admin can help us to build a
Resource
Apex. Salesforce Flow.

Apex can handle large records set in per It is difficult to handle large data volumes in
LDV
transaction. flow.

We can handle complex SOQL queries inside Complex to handle complicated queries in
Complex Queries
the Apex and triggers. Salesforce flow.

We have to write test classes to deploy the We don’t need to write any test class for flow
Test Classes
code in production. deployment.
When we perform mass updates across multiple unrelated records, or complex logic into opportunity
conversion, the flow should be triggered. The below table provides the flow to be trigger:
 Sets of rules and regulations that restrict the monopolistic use of the resources on the cloud by this or that
organization that utilizes Salesforce servers.
 Prevent the abuse of the resources (such as memory, database, number of processed records and script
statements, etc.) by establishing constraints that restrict the implementation of code and Apex runtime.
Types of Salesforce Governor Limits
 Per-Transaction Apex Limits - Such limitations are applicable for every Apex transaction; what’s for Batch Apex
cases, limitations are reset
 Per-Transaction Certified Managed Package Limits - Such limits are applied to the packages installed to an org
with a namespace, such packages were created by SFDC partners and have successfully passed the majority
transaction limit security checks run by the AppExchange
 Lightning Platform Apex Limits - Such limitations are enforced by the platform as they aren’t particular to Apex
transactions
 Static Apex Limits - Restricts loop and apex trigger sizes, callout sizes and times, trigger code unit numbers, etc.

 Size-Specific Apex Limits - As evident from the name, such limits are used to regulate sizes so that no
inappropriately sized items are used in all the classes.
Types of Non-Apex Salesforce Governor Limits
 Inbound Email Limits

 Push Notification Limits

 Governor Limits for Salesforce API Requests

 Chatter REST API Limits

 SOAP API Call Limits

 API Query Cursor Limits

 Metadata Limits

 SOQL and SOSL Governor Limits in Salesforce

 Visualforce Limits
Overview Governor Limit
Total number of SOSL queries issued in Salesforce 20

DML Governor Limits in Salesforce (Total number of 150


issued statements per transaction)

Total number of records retrieved by a single SOSL 2000


query
Total number of records that were retrieved by SOQL 50000
queries
Total number of records retrieved by 10000
Database.getQueryLocator

Salesforce Governor Limits for heap size total 6 MB/12 MB


• A Salesforce report is a list of data generated based on filter criteria.
• Salesforce Reports helped us predict trends and gave us the advantage of increasing profits.
• Admin can create reports quickly and can schedule the reports.
• Salesforce Dashboard or chart can be used to visualize and analyze your Salesforce report data.

Different Types of Reports in Salesforce:


1. Tabular Report - A report that provides details of a company in tabular format. It is used when you want a
simple or item list with a total. These reports are used to list all accounts, list of opportunities, list of contacts,
etc.
2. Summary Report - A report that provides a listing of data with groupings and subtotals. It is used when
subtotals are needed, based on the value of a particular field, or when you want to create a hierarchically
grouped report. For example, all opportunities for your team are subtotaled by owner and sales stage.
3. Matrix Report - A report is formed by grouping the records by rows and columns. It is used when you want
to see data by two separate dimensions that aren’t related, such as date and product. For example,
Summarize opportunities by account horizontally and by month vertically.
4. Joined Report - The mixture of any combination of reports creates a report. Like matrix report plus
summary report can give you a joined report. Also, matrix reports and tabular reports can give a merged
report. Example: You can develop a report to display your accounts’ opportunity, case, and activity data.
Tabular Report - A report that provides details of a company in tabular format. It is used when you want a
simple or item list with a total. These reports are used to list all accounts, list of opportunities, list of contacts,
etc.
Summary Report - A report that provides a listing of data with groupings and subtotals. It is used when
subtotals are needed, based on the value of a particular field, or when you want to create a hierarchically
grouped report. For example, all opportunities for your team are subtotaled by owner and sales stage.
Matrix Report - A report is formed by grouping the records by rows and columns. It is used when you want to
see data by two separate dimensions that aren’t related, such as date and product. For example, Summarize
opportunities by account horizontally and by month vertically.
Joined Report - The mixture of any combination of reports creates a report. Like matrix report plus summary
report can give you a joined report. Also, matrix reports and tabular reports can give a merged report. Example:
You can develop a report to display your accounts’ opportunity, case, and activity data.
Click on the “Report” tab
Then select the “New report” button

Select the object on which you want to create the report. Then click on the Start Report button.
Once you click on start report, the below canvas will open.
Outline: You can drag and drop a field from here
Filter: You can add a filter from the Filter tab
Update Preview Automatically: Turn this one to see an update on the report without a refresh.
Click on the Save button to save the report and provide the Report name and unique name.
• API-led connectivity is a methodical way to connect data to applications through reusable and purposeful APIs within
an organisation’s ecosystem.
• These APIs are developed to play a specific role: unlocking data from systems, composing data into processes, or
delivering an experience.
Building blocks are the most fundamental unit of the composable enterprise.
• They have a clearly articulated purpose of driving a business or technology outcome.
• They can be automated and orchestrated with other capabilities, making them interoperable.
• They are discoverable, accessible, and manageable.
• They represent the “nouns and verbs,” or the “vocabulary” of your business.

You might also like