LECTURE 4: SALESFORCE SECURITY MODEL

In this lecture we will learn how to secure your Salesforce organization by controlling
exactly what data your users have access to within it.
There are 4 main levels in Salesforce Security Model:

Let's check them one by one:

1 LEVEL: THE ORGANIZATION
“Who can even Log in to Salesforce?” This is the main question of this security level.
So, how do you control access to your Salesforce Organization? You do this by managing
authorized users, setting password policies, and limiting when and where users can log in.
Let’s check how we can ensure that only eligible users are logged in :
1. Set Trusted IP Ranges for Your Organization
Trusted IP Ranges define a list of IP addresses from which users can log in without
receiving a login challenge for verification of their identity, such as a code sent to
their mobile phone. For example, suppose that your users should be able to log in
without entering a verification code whenever they are in the office. However, this
does not restrict access, entirely, for users outside of the Trusted IP Range (out of
office network). Users outside of the office would be forced to go through
verification step ( e.g. verification code). Related Article , Related Trailhead
Module
2. Restrict Login Access by IP Address Using Profiles
You can control login access by specifying a range of allowed IP addresses on a
user’s profile. When you define IP address restrictions for a profile, a login from
 any other IP address is denied. Related Article, Related Trailhead Module, Related
Trailhead Module
3. Restrict Login Hours
Basically, you can specify the hours when users can log in based on the user
profile. For example, you have the Customer Managers Team who works from 9
am to 6 pm on business days and you don’t want them to be able to log in beyond
those hours. These where “Restrict Login Hours” is useful, because you can
restrict Customer Managers team login before 9 am and after 6pm as well as on
weekends. Related Article, Related Trailhead Module
4. Use Session Settings.
Session Settings control required session security level and timeout for inactive
sessions. For example, you can control how long a user can be inactive in
Salesforce before system will logout him. Related Article
2 LEVEL: OBJECT
First, we need to remember that here are three key constructs related to data in
Salesforce: objects, fields, and records. Objects are like tables in databases. Fields are
like columns of the table. Records are like rows of data inside the table. Useful GIF
So, Object-Level Access can be managed through:
1. Profiles and Permission sets.
[IMPORTANT] Each user is assigned one profile. Permission sets are more
flexible. In contrast to profiles, you can add multiple permission sets to a given
user.
A user’s profile determines:
• What can a user see? (e.g., Tabs, Layouts, Apps etc.);
• What can a user do with objects and fields? (The objects they can access and
the things they can do with any object record such as create, read, edit, or
delete (CRED Permissions);
• What can a user do in Salesforce Environment? (e.g., Systeme Permissions);
• When or where a user can login? (see “1 LEVEL: THE ORGANIZATION”)
A permission set is a collection of settings and permissions that give users access
to various tools and functions. The settings and permissions in permission sets are
also found in profiles, but permission sets extend users’ functional access without
changing their profiles. Basically, Permission sets grant additional permissions and
access settings to a user. Permission Set will never restrict access. Related
Trailhead, Useful GIF on how to assign Permission Set
 2. License.
A user license determines the baseline of features that the user can access. Every
user must have exactly one user license. Related Article
3 LEVEL: RECORD
Record-level security is often referred to as the Salesforce sharing model, or just simply
“record sharing” or “sharing”.
How to set up a proper record sharing model? First ask yourself these questions:
“Should your users have open access to every record, or just a subset?”
If it’s a subset, what rules should determine whether the user can access them?
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. Basically, record access determines which individual records
users can view and edit in each object they have access to in their profile.
Let's have a look at how record sharing is opened up:

All blocks here are listed in order of increasing access. You use org-wide defaults to lock
down your data to the most restrictive level, and then use the other record-level security
tools to grant access to selected users, as required.
1. Org –Wide Defaults.
In Salesforce, records have a field called “OwnerId” that points to a real user.
 Owners of records are usually people who created the record and have full CRED
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. OWD answers the question: “Who else except the
owner?”
There are several most common types of OWD:
- Private (Only the record owner, and users above that role in the hierarchy, can
view, edit, and report on those records.)
- Public Read Only (All users can view and report on records, but only the owner,
and users above that role in the hierarchy, can edit them.
- Public Read/Write (All users can view, edit, and report on all records)
- Controlled by Parent (A user can view, edit, or delete a record if she can perform
that same action on the object it belongs to.)
You use organization-wide sharing settings to lock your data to the most restrictive
level. Then you will be able to use other record-level security and sharing tools to
selectively give access to other users.
For example, users have object-level permissions (on Profile) to read and edit
opportunities, and the organization-wide sharing setting is Read-Only. By default,
those users can read all opportunity records, but can’t edit any unless they own the
record or are granted other permissions. Organization-wide defaults are the only
way to restrict user access to a record. Related Trailhead , Useful GIF
2. Role Hierarchy.
Typically, in an organization, different job roles have different record access
requirements. Users who need to see a lot of data (such as the CEO, executives, or
other management) often appear near the top of the hierarchy. But role hierarchies
don't have to match your org chart. Each role in the hierarchy just represents a
level of data access that a user or group of users needs.
Let's imagine you have a newcomer to sales executive team named Maria. You
need to Find a proper place for here in your Role Hierarchy. Check this GIF on
how to achieve that.
Users higher in a hierarchy (role or territory) inherit the same data access as their
subordinates for standard objects. Managers (for e.g. Maria ) gain as much access
as their subordinates. If the subordinate has read-only access, so will the manager.
This access applies to records owned by users, as well as records shared with them.
What about custom Objects? By default, the Grant Access Using Hierarchies
option is enabled for all objects. It can only be changed for custom objects.
Related Trailhead
3. Sharing Rules
Hierarchy-based sharing (we learned above) 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 Maria owns (records of sales executive team) with her
peers in the service executive teams? This is where sharing rules come in. Sharing
rules provide a way to share records laterally and in an ad-hoc fashion via public
groups.
Let’s look into the details:
Ownership-based sharing rules let admins share records based on role, role-and-
subordinate, and public group ownership. For example, we can share all the
records owned by anyone in a sales executive role (including Maria’s) with
everyone in a service executive role. Similarly, we can share all the records owned
by the sales executives, and their subordinates, with others as well.
The GIF shows how different ownership-based sharing works for our use case.
Note that the public group is an ad-hoc group of individual users, users in various
roles, and other public groups. Sharing with public groups provides a highly
flexible way to share records.
Criteria-based sharing rules let users access records based on the value of a field
in a record, irrespective of who owns the record. For example, if Maria wants to
meet with all accounts in San Francisco, an admin might set a criteria-based
sharing rule to share with Maria all accounts whose billing city is San Francisco.
Useful GIF,
[IMPORTANT] Sharing Rules open up records access to users when OWD is set
to anything more restrictive than Public Read/Write. Related Trailhead
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. [IMPORTANT]: This is only
available if the OWD is private or public read-only because otherwise (say public
read/write), you wouldn’t need it. Useful GIF, Related Trailhead
5. Teams
For accounts, opportunities, and cases, record owners can use teams to allow other
users access to their records. A team is a group of users that work together on an
account, sales opportunity, or case. Record owners can build a team for each
record that they own. The record owner adds team members and specifies the level
of access each team member has to the record, so that some team members can
have read-only access and others can have read/write access. The record owner can
also specify a role for each team member, such as “Executive Sponsor.” In account
 teams, team members also have access to any contacts, opportunities, and cases
associated with an account. Related Article
4 LEVEL: FIELD LEVEL SECURITY
In some cases, you want users to have access to an object, but limit their access to
individual fields in that object. Field-level security settings—or field permissions—
control whether a user can see, edit, and delete the value for a particular field on an
object. These are the settings that allow us to protect sensitive fields such as a candidate's
social security number without having to hide the candidate object. For example, an
object can have 20 fields, but field-level security can be set up to prevent the users from
seeing five of the 20 fields.
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 from specific user. When you
hide a field with field-level security , the field won’t be accessible through any entry
points (for instance via API). The recommended security best practice is to use field-level
security instead of just removing a field from a page layout. Just as with object-level
security, we recommend to configuring field-level security using permission sets and
permission set groups.
The graphic here shows how you provide field-level access through a permission set.
Related Trailhead
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. Further, there are five types of record-level security: org-wide defaults, role
hierarchy sharing, sharing rules, manual sharing, and teams sharing. These five control
access to sets of records or even an individual record to people who don’t own those
records.
Keep in mind that permissions on a record are always evaluated according to a
combination of object-level, field-level, and record-level permissions. When object-level
permissions conflict with record-level permissions, the most restrictive settings win.