The profile is like a Key to House.

Permission sets are like keys to individual Rooms

The key difference between the two is that the Profile is the user's base set of permissions and all users
are assigned to one. ... Profiles can be used to give or take away permission from the users assigned to
them. Permission Sets can only give or extend permission to the users assigned to them.

Permission sets - These are used to grant additional permission to a user.

Profiles: In Object level Security, Profiles are assigned to the user by the system administrator. A profile
can be assigned to many users where a user can have only one Profile

‘Object Level Security :

1. Profile: Object level security is determined by a profile assigned to a particular user.

Profile controls Objects that a user can see and what they can do on these objects, these
settings are called CRED (Create, Read, Edit, Delete)

2. Permission sets: Permission sets are used to provide additional (usually special)
permissions to users who are already assigned a profile
Role : which control what users can see in your Salesforce org.

Profiles control what users can do in your Salesforce org. This can be referred to as CRED:

 C = create
 R = read
 E = edit
 D = delete
You may want some users in your org to read and edit Leads, but not delete them. CRED enables you to
mix and match what a specific user can do with each object.
See how this looks on a profile’s settings (found under the ‘Object Permissions’ section):

In addition to objects, profiles also control:

 Field-level security (which fields are visible or editable),

 Page layouts,
 Record types,
 Apps,
Each Salesforce user in your org has a profile. Profiles are designed to group users into functions, for
example, ‘Sales’, ‘Support’ etc.

The most important profile in the org is ‘System Administrator’. Users in this profile have absolute
access to do anything. In addition to CRED, they will have ‘View all’ and ‘Modify all’ selected for each
object.

They will also have ultimate permissions, namely ‘Modify all data’, ‘Customize application’ that you
would not want to give to any other users! (found under the ‘Administrative Permissions’ section).

What is a Salesforce Role? – and the Role Hierarchy

Let’s switch to thinking about roles, which control what users can see in your Salesforce org.

Roles are designed to increase data visibility, to open up access to Salesforce records. You will have a
baseline visibility set for each object in your org, known as the ‘org wide default’ (organizational wide
default, OWD). Examples of this could be:

 Opportunities are set to ‘Private’, which means that users can only see the opportunities they
own.
 Accounts are set to ‘Public Read/Write’, so that any user can help to update account
information.

You should know that there are defaults that are already set. I’m not going to dive into details on OWD
right now, but I want you to remember the golden rule…

Golden rule: the ‘org wide default’ should be set to the most restrictive level. Salesforce permissions
work by opening up access, not by locking them down. So, start with the strictest in mind.

There are two ways to increase data visibility via roles, essentially superseding (pushing past) the OWD:

 The Role Hierarchy

 Sharing Rules
 
 Note: Sharing Rules are used to extend the Role Hierarchy, so that you are not restricted to the
strict top-down sharing as laid out in the hierarchy – in other words, Sharing Rules can enable
you to open up record visibility horizontally across the hierarchy.

What’s the Difference Between a Role and Profile in Salesforce?

Profile Role
Determines Do - create, read, edit, See - record visibility
what users delete
can...
Required for ✓ X - it’s optional
each user?
Imagine in the Circles, grouping users Hierarchy, that splits
shape of: with similar functions. users with more
authority from those
with less.
Controls Objects, field-level Records, folders.
access to: security (which fields are
visible or editable), page
layouts, record types,
apps, tabs.
 Showing 1 to 4 of 4 entries
 PreviousNext
 What About Permission Sets? (Permission Sets vs. Profiles)
 Once you have got to grips with profiles and roles, you have mastered a core Salesforce Admin
concept that will serve you well. What about permission sets, then? Not another Salesforce data
access concept! Fear not, I will explain the differences between profiles and permission sets
quickly, and painlessly.
 Permission sets could be considered add-ons for profiles. They offer flexibility in how you add
certain permissions (objects, field-level security, page layouts, record types, apps, tabs) to
certain users – almost like you are tagging an individual user. In order to grant a very specific
ability to a user, you obviously don’t want to create a whole new profile just for that one
difference between their abilities and the rest of their team’s!


 Let’s take an example:
 There is a sales team, who have the profile ‘Sales User’. Only Carole should be able to change
the team’s email templates, so the Admin has created a Permission Set called ‘Modify Email
Templates’ which she has added to Carole’s user record.
 Permission sets are visible from the related list on the user’s record:
 
 Permission sets can simply be added and removed, from ‘Available Permission Sets’ to ‘Enabled
Permission Sets’ – as shown below:


 You should also be aware of Permission Set Groups. These were new in the Spring ‘20 release,
created to revolutionize how Admins can organize org permissions, allowing Permission Sets to
be grouped together and assigned to users.

Permission

Profile : is nothing but a component Which contains a group of permissions can be assigned to one or
more users inside the organization

by using profile we can grant /restrict the permissions on all the features available in the
organization(app,tabs, fields ,objects,coding)

Profile determines what user can do in salesforce

Standard profile and custom profile

While creating user each user should be associated with license and profile

1 user->1 license ->1 profile

Profile is acting as a mediator between user and license/organization where if the organization
provides the full permission , then the profile can control the access to the user
Profile controls:

 Objects
 Fields
 Record types
 APPS
 Tabs
 General permissions
 Login IP ranges
 Administrative permissions

Relationship:

One object lo information inko object ki share cheyatam

  Master detail relationship
 Look up relationship
 Self relationship
 External lookup relationship
 Hierarchal relationship
 Many to Many relationship (junction object)

Lookup is loosly coupled relationship among salesforce objects which means if the parent record
gets deleted the child record remains in the system both the parent and child have their own sharing
settings and controls

 Roll up summary field cannot be created

 Parent record is not required while creating child record
 You can have a child record without a parent

Master detail :it is strongly coupled relationship among salesforce objects which means if the master
record gets deleted the child record associated with it gets deleted in this type of relationship the
parent record controls the child record regarding visibility and sharing .it means the security setting of
the parent object applies to child object

Roll up summary field can be created

Cascade delete

Parent controls the record ownership of the child records

Many to many
Difference between workflow and process builder

If there are two users who are set to OWD equal to private and i want to grant permissions to them
how can i do that

On account object owd is private and profile level access is read only will still user can see the account?

User is not having cred permission even he is not having view all and modify all permission and owd is
private still he is able to create record. What could be the possible reason ?- May be a permission set is
assigned or may have modify all data permissions

Salesforce provides a secure and flexible data security model to secure data at different levels.
Org Level Security

Object Level Security

Field Level Security

Record Level

It all start with Object, field and record.

Lets have a look at above terms.

Object- They are similar to database tables that store the information

Field- They are the column from that database table

Record - Records are similar to rows of data inside the table.

Salesforce also provides sharing model to open up and allow secure access to data based on business
needs.

Layer 1: Object Level Security.

Object-level access can be managed through two configurations - Profiles and Permission Sets.

Access given- Create, Read, Edit, Delete, View All, Modify All

Profiles

Assigning a user a profile is compulsory, as this is the place where you configure other things like page
layout assignments or login IP restrictions. However, for object and field security setup, configure
profiles for minimum access and use permission sets to add permissions.

Permission sets
Permission sets are more flexible. In contrast to profiles, you can add multiple permission sets to a given
user. This gives you much more flexibility at the time of designing your security model, as functionality
can be grouped in more granular ways. When only using profiles, you needed to group all the object and
field permissions in a single profile, for instance for a concrete job role, as sales exec. With permission
sets you can have different permission sets representing the different tasks that that a sales exec
performs: manage leads, approve opportunities, etc. and add or remove smaller chunks of permissions
to a user at any time.

Layer 2: Field-level Security

Access given- Read, Edit, Hidden

Even if a user has access to objects, he/she still needs access to individual fields of each object. In
Salesforce, profiles and permission sets also control field-level access.

An admin can provide read and write permissions for individual fields. An admin can also set a field to
hidden, completely hiding removing access to the field to from that user. When you hide a field with
field-level security , the field won't be accessible through any entry points (for instance via API).

Layer 3: Record level Security

Record-level security is often referred to as the Salesforce sharing model, or just simply "record sharing"
or "sharing".

Salesforce provides five ways to share records with others and access others records. You start by
configuring org-wide defaults, to lock down your data to the most restrictive level. Then you use the
other record-level security tools to grant additional access to selected users when needed.

1:- Organization-Wide Sharing Defaults

2:- Role Hierarchies

3:- Sharing Rules

• Ownership-based Sharing Rule

• Criteria-based Sharing Rule

4:- Manual Sharing

5:- Apex Managed Sharing

1:- Organization-Wide Sharing Defaults

In Salesforce, records have a field called "Ownerld" that points to a real user. Owners of records are
usually people who created the record and have full CRUD (create, read, update, delete) access to it.

Organization-wide defaults (OWD) control the default behavior of how every record of a given object
(for example, Accounts) is accessed by users who do not own the record.

2:- Role Hierarchies

Typically in an organization, different job roles have different record access requirements. Normally job
roles are sorted in a hierarchical way: users with a higher role should have access to records to which
users in lower roles have access.

Note that a role hierarchy rarely maps to an org chart. It really maps hierarchies of data access.
Salesforce provides an easy way to share records with managers and represent a role hierarchy. To use
this sharing rule, an admin must first add the user to a role and grant access.

3:- Sharing Rules

Hierarchy-based sharing only works for sharing upward and in a vertical direction. What if we want to
share laterally? For example, what if we want to share records that a user owns with his/her peers in the
same team? This is where sharing rules come in.

Sharing rules provides away to share records laterally and in an ad-hoc fashion via public groups.

Let's look into the details.

• Ownership-based Sharing Rule

Ownership-based sharing rules let admins share records based on role, role-and-subordinate, and public
group ownership.

• Criteria-based Sharing Rule

Criteria-based sharing rules let users access records based on the value of a field in a record, irrespective
of who owns the record.

4:- Manual Sharing

Manual sharing provides a mechanism to share individual records with others. This permission is
accessed through the Sharing button on the record details page, and lets end-users share individual
record with others.

Please Note: This is only available if the OWD is private or public read-only because otherwise (say
public read/ write), you wouldn't need it.

5:- Apex Managed Sharing

There are occasions when you can't share records via UI or settings, but you need to write Apex code to
do so.

Level of data access:

We have four different levels of data access in Salesforce.com. They are

 Organization level Security.

 Objects level Security
 Field level Security
 Record level Security

1. Organization level Security:

Organization level security is the highest level of security in Salesforce where we maintain a list of
authorized users to login, Password policies, Login IP ranges, limiting login access to certain hours,
Session Security, Login Flows, Network Access.
2. Object level Security:

Before allowing a user access, Salesforce first verifies that the user has permissions to see objects of that
type. Object-level access can be managed through two configurations, profiles and permission sets.

2.1 Profiles:

A profile contains the baseline permissions of a user, and each user is assigned only 1 profile. It defines a
user’s ability to peform different functions, access records, and the way the records are displayed.
Profiles are tied to a user license.

2.2 Permission Sets:

A permission set is a collection of permissions that can be assigned to a user extending users’ functional
access without changing their profiles. Users can have only one profile but they can have multiple
permission sets.

3. Field level Security:

Field level security in salesforce controls whether a user can see, edit or delete the value for a particular
field on an object, unlike page layouts which only control the visibility of the field on detail and edit
pages of an object. It secures the visibility of fields in any part of the app including related lists, list
views, reports, and search results.

Field level security can be applied to multiple fields on a single profile or permission set and can also be
applied to a single field on all profiles.

4. Record level Security:

Record level access can be controlled in four distinct ways. We have ordered them below, the access
level as we go in the ascending order to the last item. This means the first item will be more restrictive,
while the last one will be least restrictive with more access. We use the OWD to provide a higher level of
restriction to the data, while manual sharing gives a higher level of access.

1. Org Wide Default (OWD): OWD specifies the default access level for the users, to access the records
of the other users.

2. Role Hierarchies: This is role-based access, and can be incorporated with OWD to ease out the access.
For example, a manager needs to access the data of subordinates. In this case, each role defined in the
hierarchy defines the level of access within the Org.

3. Sharing Rules: Sharing rules enable default exceptions to OWD for a specific group of users. We can
apply the rules readily to a public group. This gives access to the users for accessing records which
otherwise they cannot access. Thus giving a higher level of access, in comparison to the last two options.
4. Manual Sharing: In manual sharing, the record owner themselves can provide access to other users,
who don’t have access.

If we look at the pyramid above, we can see that manual sharing has got the most eased out access,
while OWD has got the most restrictive access. In other words, as we go down the pyramid, the record
level access gets more restrictive.

The security controls are based on the principles given below.

 The user’s profile determines their baseline permissions.

 Assigned permission sets are based on the profile.
 OWD determines the permission to other records that are not owned by the user.
 Sharing rules can be used for expanding access to the additions user groups. As from the
pyramid, we can already see that the sharing level provides the maximum level of access.

Summary:

Salesforce provides four layers of security with lots of flexibility to accommodate virtually any business
need. Profiles and permission sets controls object-level and field-level access, with permission sets being
our recommended tool to use.

Further, there are four types of record-level security: org-wide defaults, role hierarchy sharing, sharing
rules, and manual sharing. These four control access to sets of records or even an individual record to
people who don’t own those records.

In Salesforce, data is stored in three key constructions: objects, fields, and records. Objects are similar
to tables in databases. Fields are similar to columns of the table. Records are similar to rows of data
inside the table. Salesforce uses object-level, field-level, and record-level security to secure access to an
object, field, and individual records.
Layer 1: Object-level-security

This layer controls the access based on the Profiles and Permission sets, we all know what these are.

Profiles: Gives you access to control object-level and field-level security among other things like apps,
tabs, and so on. I can control what a user can see based on his/her profile. A very basic thing to enforce
security.

Permission Sets: Suppose, a certain user in a profile needs to have access to certain objects, which are
not visible by his/her profile. Create a permission set, assign the necessary access level, you are good to
go.

Layer 2: Field-level-security

As discussed with profiles and permission sets, we can control the access to objects, fields, tabs, etc.
What if we have access to an object and its fields, but we do not wish everyone to see all fields. Ok, you
can see but I don't want them to edit these field's values, field-level security helps me to control this.

Layer 3: Record-level-security

This the most important aspect of the data security model. This is where the real deal lies. We know that
every record created in Salesforce is owned by a user. That user has absolute control over that record.
Just like my Facebook example do I want everyone to see my records, can I control this? If yes then how
and up to which level. The below image shows record level security flow which gives us the power to
control security

Organization-Wide Defaults: OWD controls the default behavior of how every record of a given object
(for example, Accounts) is accessed by users who do not own the record.

For example:

1. If OWD for Accounts is Private, it means only the record owner can see the records.
2. If OWD for Accounts is Read/Write, it means anyone can read and update (but not delete) the
record.

Role Hierarchies: We know that every organization has its own set of Roles. In Salesforce Roles control
the visibility of the data. A certain user who is higher than you in terms of the organization roles can see
your data.

Sharing Rules: the Roles will expand the data visibility when we traverse upwards in roles. What if I want
to share my data with my peers in my team or a certain role or group? This is where Sharing rules kick in.

 Ownership-based Sharing: Ownership-based sharing rules let you share records based on role,
role-and-subordinate, and public group ownership. This means I can share all the records owned
by me throughout my role.
 Criteria-based Sharing: Ok, all of the above is fine, but I want this to be kind of dynamic. I want
to make sure as soon as an Opportunity in London is Closed Won. This record should be shared
with a certain role, role-and-subordinate, and public groups. We will create some criteria-based
sharing rules for Opportunity, under Sharing settings. Define your criteria, save, recalculate, and
it's done. So now every time an Opportunity meets the criteria, it is shared with specific people.
 Guest user access, based on criteria: Sometimes we want some of the very generic data to be
available to the guest users who are accessing the site, even without logging in. Again here also
you can define your criteria, but this is advised only for something which you think is
 appropriate for the sensitivity of your data. Salesforce isn’t responsible for any exposure of your
data to guest users related to this change from default settings.

Manual Sharing: Fine, everything makes sense, but what if I want to be too selective to share my data. I
can do this using the Sharing button available on the Page Layout. This provides a mechanism to share
individual records with others. Something to note, this is only available if the OWD for the object is
private or public read-only.

Apex Managed Sharing: There could be an instance where we have to meet bit complex criteria and this
cannot be achieved using out-of-the-box features. I can pull this by writing some custom apex code.
More details can be found here.

Hope this helps you in some way.

5. What is Manual Sharing in Salesforce, and under what circumstances would you use it?

Answer: Manual Sharing in Salesforce is a feature that allows record owners or administrators to
manually share individual records with specific users or groups. It’s typically used when there are
exceptional cases where certain users need access to specific records that they wouldn’t normally have
access to based on the standard sharing rules or OWD settings.

6. Describe the concept of Role Hierarchy in Salesforce and its role in data access control.

Answer: Role Hierarchy in Salesforce is a structure that defines user access to data based on their roles
within an organization. It influences data visibility and access control by granting higher-level users
access to records owned by lower-level users in the hierarchy. It ensures that users at higher levels can
access records owned by users beneath them in the hierarchy.

7. How does the Grant Access Using Hierarchies feature in Salesforce influence data visibility?

Answer: The “Grant Access Using Hierarchies” feature in Salesforce influences data visibility by allowing
users at higher levels of the role hierarchy to have access to records owned by users at lower levels of
the hierarchy. This feature ensures that managers or supervisors can access the records of their
subordinates.

8. What are Profiles in Salesforce, and how do they contribute to data security?

Answer: Profiles in Salesforce are sets of permissions and settings that determine what users can access
and do within the organization. They contribute to data security by defining the baseline permissions for
users, including what objects they can see and edit.

9. Explain the purpose of Permission Sets in Salesforce and how they can be used to grant additional
permissions to users.

Answer: Permission Sets in Salesforce are used to grant additional permissions to users beyond what
their profiles allow. They can be assigned to users or groups as needed to provide additional access or
functionality.

10. What is Field-Level Security, and how can it be applied to restrict access to specific fields within an
object?

Answer: Field-level security is a feature in Salesforce that allows administrators to control which users
can view or edit specific fields within an object. It is applied to restrict access to sensitive data within
fields.

11. What is the difference between Profile-level and Field-level security settings in Salesforce?

Answer: Profile-level security settings in Salesforce apply to all records and fields for a specific object.
They determine the default access level for all users with that profile. Field-level security settings, on the
other hand, allow you to further restrict access to individual fields within an object.

12. How can you secure sensitive data in Salesforce by leveraging Encryption?

Answer: Encryption in Salesforce is a security feature that converts sensitive data into a coded format,
making it unreadable without the decryption key. It is used to secure data both at rest and in transit,
ensuring that even if unauthorized access occurs, the data remains protected.

13. Describe the purpose of Data Categories and how they can be used for data classification and access
control.
Answer: Data Categories in Salesforce are used for data classification and access control. They allow you
to categorize records and control who can access them based on their category. Data Categories help in
organizing and securing data effectively.

14. What is Object-Level Security, and how does it differ from Record-Level Security in Salesforce?

Answer: Object-level security in Salesforce controls whether a user can see and interact with an entire
object, not individual records within it. It sets the baseline for access to all records of a specific object.

15. What is the significance of Apex sharing rules in Salesforce, and when would you use them?

Answer: Apex sharing rules in Salesforce are used to programmatically share records based on custom
logic or criteria. They provide more flexibility than standard sharing rules and allow for complex sharing
scenarios.

16. How can you use Criteria-Based Sharing Rules to dynamically share records in Salesforce?

Answer: Criteria-Based Sharing Rules in Salesforce allow you to dynamically share records based on
specific criteria, such as record owner or field values. They are useful when you need to share records
based on specific conditions.

17. Explain the concept of Sharing Groups and their role in data sharing.

Answer: Sharing Groups in Salesforce are sets of users that you can use in Sharing Rules. They simplify
sharing by letting you share records with a group of users instead of specifying individual users.

18. What is Manual Sharing and why might it be necessary to manually share records with specific
users?

Answer: Manual Sharing in Salesforce is used when you need to manually share specific records with
individual users or groups who wouldn’t otherwise have access. It provides a way to grant exceptional
access to specific records.

19. Describe the implications of the "View All" and "Modify All" permissions in Salesforce.

Answer: The “View All” and “Modify All” permissions in Salesforce allow users to bypass most sharing
rules and gain broad access to records, even if they don’t own them. These permissions should be
carefully managed and granted sparingly.

20. How can you use Permission Sets to assign additional permissions to users who belong to different
departments or roles?

Answer: Permission Sets in Salesforce can be used to assign additional permissions to users who belong
to different departments or roles. They allow for fine-grained control over access based on specific
needs.

21. Discuss the use of Data Classification in Salesforce and its role in data protection.
Answer: Data Classification in Salesforce helps categorize data based on its sensitivity and business
importance. It is crucial for determining access control policies and ensuring that data is appropriately
protected.

22. What are Record Types, and how can they be used to control data access based on specific criteria?

Answer: Record Types in Salesforce are used to provide different page layouts, picklist values, and
business processes for different categories of records. They can control data access based on record
type, allowing for different levels of access for various record categories.

23. Explain the purpose of Implicit Sharing in Salesforce and when it comes into play.

Answer: Implicit Sharing in Salesforce automatically grants certain users access to records they don’t
own based on relationships defined in the organization. For example, a manager can access records
owned by their subordinates.

24. What is the "View All Data" and "Modify All Data" permission and how should they be managed in
Salesforce?

Answer: The “View All Data” and “Modify All Data” permissions in Salesforce are powerful permissions
that allow users to view and modify all records, regardless of sharing settings. These permissions should
be managed with extreme caution and only granted to users who truly require them.

25. How can you restrict access to certain fields within an object for specific profiles or permission sets?

https://www.youtube.com/watch?v=eRMif9cFTpc

What Integration options are available in Salesforce?

There are lots of Integration options available in Salesforce. Here is the Salesforce Integration
Cheatsheet.

Data
S.No API Name Protocol Communication
Format

1 REST API REST JSON, XML Synchronous

Apex REST JSON, XML,

2 REST Synchronous
API Custom

SOAP
3 SOAP API XML Synchronous
(WSDL)

Apex SOAP SOAP

4 XML Synchronous
API (WSDL)
 Chatter REST Synchronous (photos are
5 REST JSON, XML
API processed asynchronously)

Analytics
6 REST JSON, XML Synchronous
REST API

User
7 REST JSON Synchronous
Interface API

REST or
JSON, XML,
8 Tooling API SOAP Synchronous
Custom
(WSDL)

9 Bulk API REST CSV Asynchronous

Metadata SOAP Asynchronous. Retrieve, deploy,

10 XML
API (WSDL) and modify metadata

Asynchronous. Push
Streaming notifications from Salesforce to
11 Bayeux JSON
API subscribing applications/entities
(replaces polling).
Let’s see the options available in Salesforce and when to use which Salesforce API for Integration.

11.1.3 Change Data Capture

Change Data Capture is a streaming product on the Lightning Platform that enables you to integrate
your Salesforce data with external systems efficiently. Change data capture is also called CDC. With
Change Data Capture, you can receive changes in Salesforce records in real-time and synchronize
corresponding records in an external data store.

1.1.4 Platform Event

Platform Event is based on Event-Driven Architecture, enabling apps to communicate inside and outside
of Salesforce. Platform events are based on the publish/subscribe model and work directly with a
message bus that handles the queue of incoming events and processes listening for them. This is built in
real-time integration patterns in the Salesforce Platform, which helps to reduce point-to-point
integration.

Ways to Fetch data from SFDC

There are different way to fetch data from Salesforce.

1. Change Data Capture

2. Outbound Messaging
3. Apex Custom Code
4. Polling
5. Data Export
6. Salesforce Connector
7. Heroku Connect

Data Integration with Salesforce

There are different ways and options available for Data Integration with Salesforce.

1. Salesforce to External Systems

2. External Systems to Salesforce
3. Salesforce to Salesforce

Salesforce Integration Patterns

There are different Integration patterns like request and reply/response, Fire and forget, Batch Data
Synchronization, Remote Call In, and Data Virtualization.

In Salesforce, we have the below Integration patterns.

1. Remote Process Invocation—Request and Reply: Salesforce invokes a process on a remote system, waits
for the completion of that process, and then tracks the state based on the response from the remote
system.
2. Remote Process Invocation—Fire and Forget: Salesforce invokes a process in a remote system but
doesn’t wait to complete the process. Instead, the remote process receives and acknowledges the
request and then hands off control to Salesforce.
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.
4. Remote Call-In: Data stored in Lightning Platform is created, retrieved, updated, or deleted by a remote
system.
5. UI Update Based on Data Changes: The Salesforce user interface must be automatically updated due to
changes to Salesforce data.
6. 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.

Common Salesforce Integration Scenarios and Solutions

Here are some Salesforce Integration scenarios.

 Synchronizing Accounts from Salesforce to SAP

 Credit Card payments via an API
 Passport Check via a Background Service
 Multiple Real-Time Fitness Devices
 Querying Bulk Data from Salesforce
 Image / Document upload into Salesforce

1. Synchronizing Accounts from Salesforce to SAP

A customer would like to synchronize their Accounts with SAP. When a new Account record is created or
updated in Salesforce they would like the Account record to be created or update in SAP. There is an
existing ESB in place. The generated customer number will then be written back to Salesforce.

The Flow
Synchronizing Accounts from Salesforce to SAP

Solution
Integration Pattern Used: RPI – Fire & Forget

Integration Flow Steps

1. User saves record which invokes a record triggered flow. Flow checks if an integration related field has
been changed.
2. Flow generates a Platform Event containing: AccountId, Timestamp and Operation [Create, Update,
Delete] and publishes to Event Bus
3. ESB reads Platform Event and makes a REST API call to Salesforce to get details about the Account.
4. ESB make a call to SAP to create the Account.
5. SAP responds with status and the SAP Customer Number
6. ESB makes a REST API call to Salesforce to update the Account
o Sync Status = Success
o SAP Customer Number = XXXXXX
o Sync Error = Blank
Error Handling

2. Credit Card payments via an API

An e-commerce application built in Community Cloud – Salesforce requires users to make a payment on
an online portal. The e-commerce platform uses an online payment gateway called SecurePay.
SecurePay exposes an API to perform credit card payments. Outline how you would build an integration
for this use case. What would you use in Salesforce? Assume we are using an ESB in place. How will you
ensure that the integration is scalable and will perform under concurrency and load.

Flow

 LWC invokes an APEX method to initiate a callout and control is returned back to the page.
 APEX method receive the request and makes a synchronous callout to the specified Mulesoft ESB
Endpoint.
 Mulesoft ESB makes a call to the Secure Payment API
 Mulesoft ESB receives a response, applies any transformation and passes the response back to the
calling APEX method.
The full end-to-end flow here is Synchronous.

Solution
Integration Pattern: RPI – Request Reply

1. Transactions in Salesforce that take > 5 seconds to complete are classified as ‘Long Running
Transactions’
2. Can have a maximum of 10 Long Running Transactions at any point in time.
3. Since Winter 20 all CALLOUTS are excluded from the long running request limit so Continuation
Framework is no longer required.
Error Handling: The response passed back from Secure Pay is relayed back to Salesforce and a record
can be logged in the Error Log object and surfaced on screen.

Integration Security

1. Use Named Credentials to specify the URI of the Callout Endpoint and Authentication Parameters
2. Reference the Named Credential in the APEX Class rather than hard-coding/exposing security credentials
3. You can have named credentials with different values per environment to help with Integration Testing
in Sandbox environments
4. Create an External Credentials specifying the PROTOCOL for authentication and also associating a
permission set to the External Credential.
5. User must have profile or permission set associated to the External Credential to be able to make the
callout
6. Use Custom Headers to incorporate user details which can help streamline the service response
 3. Passport Check via a Background Service
As part of the application process for Passports, a background check has to be conducted. BackCheck is a
background checking service that takes 2-3 days to perform verification and provide a response back to
the calling service. BackCheck exposes a REST API allowing for a calling system to invoke the background
checking service. As part of this an image file containing a photo of the user must be sent via the REST
API. When a user completes an Application in Salesforce, the background check must be automatically
invoked. Once the Background check is completed, the salesforce application record must be updated
with the results. Please advise on how you would build this integration.

Flow

Solution
Integration Pattern: RPI – Fire & Forget

Integration Approach: Long Running Transaction

Mulesoft will maintain a log table with details of the fact that this transaction is awaiting a response.
When the response comes in from BackCheck, Mulesoft checks the log table and is able to complete the
job by updating the invoking record in Salesforce. This is an example of a Long Running Transaction

Create endpoint in Mulesoft to receive response from BackCheck service.

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

At high level, there are five types of integration patterns in Salesforce

1. Request and Reply

2. Fire and Forget
3. Batch Data Synchronization
4. Remote Call In
5. Data Virtualization

Also need to consider Timeout scenario when no response is received after X days. Managed via
Scheduled Flow on Record to move calling Record to Error State.
 4. Multiple Real-Time Fitness Devices
In this scenario we have multiple fitness devices (smart-watches) (10M+) which send real-time updates
on a person’s activity every few seconds. At any point in time, a user should be able to login to a
Salesforce community and see their updated activity details. How will you build this integration. Would
you have the devices send API calls directly into Salesforce, or would you consider building a back-end
service off platform to receive the real-time calls? Advise how this will work?

Solution
Pattern: Data Virtualization & Remote Call In

Goal of the architecture is to ensure that we do not have high volume inbound API calls into Salesforce.

5. Querying Bulk Data from Salesforce

We want to synchronize a volume of Billing Account records from Salesforce nightly to the Finance
system. How would you do this. Assume an ETL tool is presented. What APIs would you use to extract
the data from Salesforce to send to the finance system. How many records would we be able to pull
down from Salesforce at one go?

Flow

Bulk API Operation

Bulk API is REST based and works Async. When you make query, Bulk API decides best way to divide full
query result into chunks and send back each chunk. [PK Chunking]. Avoid timeout and process chunk
before next chunk arrives. Can do custom retrieval chunking as well.

 Step 1: Make Bulk API call with Query String

 Step 2: Salesforce gives response giving the Job ID
 Step 3: Salesforce starts retrieving data in the back-end.
 Step 4: Make request including jobID and # of records
 Step 5: Get records back in response and sforce-locator parameter.
 Step 6: Use sforce-locator to get records in sequence.
Bulk API Response

 Sforce-Locator parameter is provided in the response.

 If Sforce-Locator is not null this means that more records are present.
 Use Sforce-Locator in next Request call.

Solution
Integration Pattern: Batch Data Sync

Integration Approach: Bulk API 2.0

1. Bulk API 2.0 query jobs enable asynchronous processing of SOQL queries.
2. Bulk API 2.0 query jobs automatically determine the best way to divide your query job into smaller
chunks to avoid failures or timeouts.
3. Automatically handles retries.
4. If you receive a message that the API retried more than 15 times, apply a filter criteria and try again.
5. Response body to query job is compressed.
6. CSV is a supported response type
PK Chunking Explained

 PK chunking splits query based on record ID

 Each chunk is processed as separate batch
 Chunk size default = 100,000
 Chunk size max = 250,000
 Enable PK chunking when querying tables with more than 10 million records or when a bulk query
consistently times out.
 Use JobID and BatchID to retrieve a specific batch.
 Effectiveness of PK chunking depends on the specifics of the query and the queried data.
Bulk API 2.0 doesn’t support SOQL queries that include any of these items:

 GROUP BY, LIMIT, ORDER BY, OFFSET, or TYPEOF clauses.

 Don’t use ORDER BY or LIMIT, as they disable PKChunking for the query. With PKChunking disabled, the
query takes longer to execute
 Aggregate Functions such as COUNT().
 Date functions in GROUP BY clauses. (Date functions in WHERE clauses are supported.)
 Compound address fields or compound geolocation fields. (Instead, query the individual components of
compound fields.)
 Parent-to-child relationship queries. (Child-to-parent relationship queries are supported.)

6. Image / Document upload into Salesforce

An estate agent creates Property records in Salesforce. Against each property there is a need to upload
property images – average 20. Each image can be 10MB in size. There are 500,000 properties that need
to be migrated onto Salesforce. What is your solution for storing the images and making sure they are
accessible against the record.

Solution
Storage Calculation: 500,000 * 20 * 10 = 97,656 GB.

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. Let see what all option we have for request &
reply.

External Services : Point & click based integration from Lightning Flow. External system should provide
OpenAPI or Interagent 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

14. What is a Connected App?

A connected app is a framework that enables an external application to integrate with Salesforce using
APIs and standard protocols, such as SAML, OAuth, and OpenID Connect. Connected apps use these
protocols to authenticate, authorize, and provide single sign-on (SSO) for external apps. The external
apps that are integrated with Salesforce can run on the customer success platform, other platforms,
devices, or SaaS subscriptions.

15. What is OAuth?

OAuth is short for open authorization. OAuth 2.0 is a framework that allows for a secure way for
systems to establish trust with one another. The end goal is to obtain an access token that can be used
by to access protected resources without ever providing your username or password to the other
system.

16. What different OAuth2.0 Authorization flows are available in Salesforce?

You decide! Salesforce supports the following flows

1. SAML Bearer Assertion

2. JWT Bearer Token
3. Refresh Token
4. Web Server Authentication
5. Username-Password
6. User-Agent
7. Device Authentication
8. Asset Token
9. SAML Assertion

20. What is OpenID Connect?

OpenID Connect is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the
identity of the End-User based on the authentication performed by an Authorization Server, as well as to
obtain basic profile information about the End-User. Learn more here.

OpenID Connect Flow

22. What is Streaming API? Explain the different mechanisms of Steaming API.
Streaming API enables the streaming of events using push technology and provides a subscription
mechanism for receiving events in near real-time. The Streaming API subscription mechanism supports
multiple types of events, including PushTopic events, generic events, platform events, and Change Data
Capture events

A Salesforce entity that represents the definition of the custom data

Platform that you send in a platform event message. You create a platform
Event event and define its fields in Salesforce. The subscription channel is
based on the platform event name.

Similar to a PushTopic, Change Data Capture triggers notifications for

changes in Salesforce records resulting from a create, update, delete,
Change
or undelete operation. Unlike a PushTopic, Change Data Capture sends
Data
all changed fields of a record and doesn’t require you to specify the
Capture
fields in a query.
Event
Also, Change Data Capture sends information about the change in
headers.

23. What is Change Data Capture?

Change Data Capture is a streaming product on the Lightning Platform that enables you to efficiently
integrate your Salesforce data with external systems. With Change Data Capture, you can receive
changes of Salesforce records in real-time and synchronize corresponding records in an external data
store. Change Data Capture publishes events for changes in Salesforce records corresponding to create,
update, delete, and undelete operations.

25. What is Salesforce Connect?

Salesforce Connect is a powerful App Cloud integration service, which enables users of Salesforce
applications to seamlessly access and handle data stored in external sources, without leaving the
Salesforce native environment. Instead of copying the data into your org, you can use external objects to
access the data in real time via web service callouts.