UNIT-3-DATA SECURITY & User Management
UNIT-3-DATA SECURITY & User Management
“Data security in Salesforce deals with the security or sharing settings of data and visibility
between users across the organization.”
It means data security defines what a user can see and what operations a user can perform on
the platform.
The Salesforce platform provides a flexible, layered sharing model that makes it easy to
assign different data sets to different sets of users.
The Security and Sharing model can be configured entirely using the user interface yet it is
implemented at the API level which means any permissions specified for objects, records,
and fields apply even if a user query or update the data via API calls.
1. Organization Level
In Organizational level security in Salesforce, you can keep a list of authorized users for your
entire organization, set password policies, and restrict logins to specific hours and locations.
2. Object Level
Object-level security provides the simplest way to control which users have different kinds of
access to each and every object. By setting permissions on a particular type of object, you can
prevent a group of users from creating, viewing, editing, or deleting any records of that
object. For example, one user can only read and create student records, and another user is
having read and edit access.
3. Field Level
Field Level Security restricts access to certain fields, even for objects a user already has
access. For example, you can make the salary field in a position object invisible to
interviewers but visible to hiring managers and recruiters.
4. Record Level
Record Level security lets users access some records but not others. It is used to control data
access with greater precision. Users can have access to view an object but can be restricted to
individual records.
For example, There are various students from different courses. so, we can set the particular
user (let’s say Mohan who is having Training Manager profile) can only see the records from
the particular course(let’s say Java)
Note: Always make a table for various types of users and the level of access to data that each
user has in your organization to implement a security and sharing model.
Usernames
It must be unique across all Salesforce organizations(instances).
User Licenses
It determines which features the user can access in Salesforce. For example, you can allow
users access to standard Salesforce features and Chatter with the standard Salesforce license.
But, if you want to grant a user to access only some features in Salesforce, you have a host of
licenses to choose from. For example, if you have to grant a user access to Chatter without
allowing them to see any data in Salesforce, you can give them a Chatter Free license.
Profiles
It determines what users can do in Salesforce. Profiles should be selected based on a user’s
job function.
Roles
It determines what additional access a user has in Salesforce based on where they are located
in the role hierarchy. These are optional but each user can have only one role assigned.
Alias
An alias is a short name to identify the user on list pages, reports, or other places where their
entire name doesn’t fit. By default, the alias is the first letter of the user’s first name and the
first four letters of their last name.
Example: a user with the name ‘Rohan Sharma’ will have the alias ‘Rshar’
User records in Salesforce can’t be deleted, they can only be deactivated or frozen.
Set login and password policies, such as minimum password length, the
type of password complexity, and specifying the amount of time before all
user’s passwords expire.
User Password Expiration
Expire the passwords for all the users in your organization after a specific
duration, except for users with “Password Never Expires” permission.
User Password Resets
Specifies the number of attempts a user can make and if a user is locked
out due to too many failed login attempts, the administrator can unlock its
access.
How to restrict a user at Org Level and Profile through IP?
1. Profiles: It determines the objects a user can access and the permissions
a user has on any object record.
Settings determine what users can see for example apps, tabs, fields, and
record types whereas Permission determines what users can do for
example create or edit records of a certain type, run reports, and customize
the app.
1. Profiles Control
Object Permission
Field Permission
User Permission
Tab Settings
App Settings
Apex class access
Page Layouts
Record Types
Login Hours
Login IP Ranges
Profiles are typically defined by a user’s job function but anything that
makes sense in an organization can be created as a profile. The platform
includes a set of standard profiles. Each of the standard profiles includes a
default set of permissions for all of the standard objects available on the
platform.
2. Standard User
Standard User profile has Read, Edit, and Delete permissions to most
standard objects
3. Read Only
The Read-only users had permissions exactly similar to the standard user
but limited access to read-only.
4. Marketing User
The System Administrator profile has the widest access to data and the
greatest ability to configure and customize Salesforce. The System
Administrator profile also includes two special permissions namely “View
All Data” and “Modify All Data”.
When a custom object is created most profiles except those with modify
all data permission do not give access to that custom object.
Note:
So to overcome this, it is good to make a new profile by copying/cloning standard profiles and then
4. A profile can be assigned to many users but the user can be assigned to
only one profile at a time.
It restricts a user to access the field anywhere in the org such as in the formula field, but if we
hide it from the page layout then the user can use the field value of that field. It will only be
hidden in the page layout.
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.
Note
If it’s a subset then what rules should determine whether the user can access them?
Types of Implementing Salesforce Record-Level Security
Salesforce provides 4 ways to implement record-level sharing:
1. Org-wide defaults specify the default(base) level of access users have to each other’s
records.
2. Role hierarchies ensure managers have access to their subordinates’ records. Each
role in the hierarchy represents a level of data access that a user or group of users
needs.
3. Sharing rules are automatic exceptions to org-wide defaults for particular groups of
users, to give them access to records they don’t own or can’t normally see.
4. Manual sharing lets record owners give read and edit permissions to users who might
8. Mechanism of OWD
All users can view and report on records but not edit them. Only the
owner, and users above that role in the hierarchy, can edit those records.
3. Private:
Only the record owner, and users above that role in the hierarchy, can
view, edit, and report on those records.
Mechanism of OWD
To determine the Organization-wide default of an object consider the
below diagram:
The data may be too restrictive for some users according to org-wide
defaults but it can be opened for users who need more access using role
hierarchies, sharing rules, and manual sharing. A sharing recalculation
starts applying access changes to records whenever an update is made for
Organization-Wide Default settings. An email is sent by Salesforce
whenever it gets completed or we can see the update on Setup Audit Trail.
Note
The owner of the record will always have all the permission(as per object
level) and it is not dependent on what the record level security is set for
that user.
Identity Basics
https://trailhead.salesforce.com/content/learn/modules/
identity_basics#:~:text=Secure%20your%20org%20so%20users,apps%2C
%20orgs%2C%20and%20services.