MULTI TENANT

ARCHITECTURE
CORE ARCHITECTURE OF SALESFORCE?

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

TERMINOLOGIES USED IN SALESFORCE ARCHITECTURE

▪ 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
▪ 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 & API
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
WHAT IS APEX?
▪ 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.
FEATURES OF APEX
▪ 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.
APEX DOESN’T SUPPORT

▪ 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.
WHEN TO CHOSE APEX
▪ 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 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

▪ 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.
TYPES OF ASYNCHRONOUS PROCESS IN SALESFORCE

▪ Schedule & Batch jobs

▪ Queues

▪ @future

▪ Change Data Capture

▪ Platform Events – Event Based

▪ Continuations (UI)
ASYNCHRONOUS VS SYNCHRONOUS

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.
APEX SYNTAX

▪ 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.
COLLECETIONS IN APEX
▪ 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
LOOP IN APEX

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
4
executing the loop body.

5 do...while loop Like a while statement, except that it tests the condition at the end of the loop body.
TRIGGERS
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.
HOW TO CREATE AN APEX TRIGGER IN SALESFORCE?
▪ 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
EXCEPTIONS, TRIGGERS VS WORKFLOW
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.
HOW DO I AVOID TRIGGER ERRORS IN SALESFORCE?
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.
 TRIGGER LIMITATIONS
▪ 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.
INTEGRATIONS
IN SALESFORCE
 INTEGRATION PATTERNS IN SALESFORCE
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.
FACTORS AFFECTING PATTERN
▪ 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 ?

SALESFORCE INTEGRATION PATTERNS & BEST PRACTICES

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.
SALESFORCE INTEGRATION PATTERNS & BEST PRACTICES
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
SALESFORCE INTEGRATION PATTERNS & BEST PRACTICES
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

SALESFORCE INTEGRATION PATTERNS & BEST PRACTICES
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.