Reply

SFDC Notes
Salesforce study notes, tips and tricks!

Home Admin Cert Notes  Links Contact About Search

Home » Admin-4-Security and Access-15%

Categories Admin-4-Security and Access-15%

This chapter’s objectives are:
Analytics (1)
Communities (1) 4.1- Explain the various organization security options (e.g., passwords, IP restrictions, identity con rmation,
Developer (1) network settings)
Lead (1) 4.2- Describe the features and capabilities of the Salesforce sharing model (e.g., record ownership, organization-
Sales Cloud (1) wide defaults, roles and the role hierarchy, manual sharing, sharing rules and public groups)
Welcome (1) 4.3- Given a scenario, apply the appropriate security controls (e.g., organization-wide defaults, roles and the role
hierarchy, manual sharing, sharing rules and public groups)

Home 4.4- Describe the various settings and permissions a pro le controls (e.g., IP access, login hours, record types,
access to tabs, permissions, object permissions, eld-level security)
Admin Cert Notes 4.5- Given a scenario, determine the appropriate use of a custom pro le

0-Admin Introduction
4.1- Explain the various organization security options (e.g., passwords, IP restrictions, identity con rmation,
1–Organization Setup–1% network settings)

2–User Setup–9% Check series: Who Sees What: Data Visibility How to Series

3–Global User Interface–1%

1/10 Who Sees What: Overview (Salesforce Classic)
Share
4-Security and Access-15%

5–Standard and Custom

Objects-18%

6-Sales and Marketing

Applications-9%

7-Service and Support

Applications-6%

8-Activity Management-3%

9-Chatter-1%
Video 1 – Organization Access through Login IP, Login Hours and Trusted IP Ranges
10-Data Management-11%
1- Create and activate users and allow them to login using: Login IP (where), Login Hours (when) and Trusted IP
11-Content and Folder Ranges
Management-2%
Login IP and Login Hours will DENY access if you don’t meet their settings
12-Analytics, Reports and
Login IP, Login Hours setup under Administer } Users | Pro les – Click on Pro le and scroll down to bottom
Dashboards-13%
Trusted IP Range under Administer } Security Control | Network Access – New trusted IP Range
13-Work ow Automation-7%
Video 2 – Object Access through PROFILES

14-Desktop and Mobile
Administration-2%
15-AppExchange-2%
Links
Contact
About
Recent Comments
Priya Deepa on How to enable
Salesforce Multi-currency, and
what are its implications?
Narayanan on How to enable
Salesforce Multi-currency, and
what are its implications?
Shibu Kalidhasan on How to
enable Salesforce Multi-currency,
and what are its implications?
CJ on Admin-5-Standard and
Custom Objects-18%
Pola on Admin-9-Chatter-1%
2- Once logged in, users should have access to APPS and OBJECTS
= PROFILE. Pro le determines which Apps, Tabs and Objects he
can access, how information is displayed to the user (page layouts,
record types, eld-level security) and what Permission he has on
each Object Records (Create, Read, Edit, Delete View All and Modify All, and many other permissions.
There exists default Pro les that you can clone
Notable Pro les: see right picture. Note that System
Admin has 2 super powers: “View all” data and “Modify
all data” – these permissions override all Sharing Rules
in settings!).
As customization of standard pro les is limited, create
custom pro les prior to assigning users to pro les.
Enable “Enhanced Pro le User Interface” will give a
better Pro le page layout that is divided into 2 sections:
Access it: Build | Customize | User Interface | and
checkbox “Enable Enhanced Pro le User Interface”
App Settings: which Apps available, Object, Tabs that have access to and their speci c permissions.
For example: “Assigned Apps” checkbox which Apps this pro le can see,
Object Settings gives permission to each Object: Read, Create, Edit, Delete, View all, Modify all. Example, you can
prevent Opp deletion here. “Object Settings” also makes the tab Hidden, default O or default On (this is only for
the Tab view, unrelated to what you can see as records in reports and lists).
System Settings: Login IP and Login Hours, Password policy, System Permission (for any App)…
Access Pro le through:
Adminster | Users | Pro le | you can clone and use a pro le as a basis of a new pro le – Can assign users
from Pro le, or from User page itself.

Meta

 
Log in
Entries RSS  
Comments RSS
WordPress.org  

Video 3: Org-Wide Defaults (OWD)

3- Now that you have granted the user his Pro le, you should de ne what the user Permission is to the records that
you do NOT own? This is con gured by OWD for each Object. OWD settings determine the default record-level
permissions granted to all users for all records within each object. For instance, setting the Account object to “Public
Read/Write” will ensure that all users have “Read/Write” record-level permissions to all account records.

Pro le Permission is the Baseline Permission – starting point – the MAX permission you could have!
OWD cannot grant permissions more than the Pro le Baseline permissions
Example, if Pro le Baseline permission is CR (Create Read), and the OWD is Public Read Write, you cannot edit
ANY record as you don’t have Edit in the Pro le Baseline, even though you have Write in the OWD.
This is mainly how do I deal with records that I do not own – regardless of Tree. ANY Record that I do not own!
Until now, in Video 2, we gave the Permissions below on the right.
These are for the Records that you OWN. What about the access and
permissions of Records you don’t own?! This is Org Wide Defaults.
You set default access level for each Object (other of what you own)
Settings for each Object: Private (can’t even see), Public read, Public
Read Write, Public read Write Transfer.
Access OWD and Object Sharing Rules through:
Administer | Security Control | Sharing Settings

Video 4: Roles and Role Hierarchy

4- Until now, we have Pro le Baseline

permission (Records that you own and your
max Permission) and OWD (anything that you
do not own). What if you want to make your
manager access your records?

Role hierarchy is a way to extend access to Records when the OWD is set to anything more
restrictive than “Public Read Write”. Because if OWD is “Public Read Write”, Role is redundant
Which RECORDS users have access to = ROLE. For example, SM should have visibility to all Opps of his team.
The Role hierarchy CANNOT grant you more permission as your Baseline
pro le permission.
It can only open up access, cannot restrict access to less than what is granted
in the OWD
Note that for the Roles Hierarchy to work:
The record is owned by a user in a subordinate role.
The object has “Grant Access Using Hierarchies” enabled in the OWD.
Access Role through:
Administer | Users | Role
You will see the Role tree, you can add roles and assign users here

Video 5: sharing rules

5- Now you can share vertically through Role and Hierarchy, but what if you want to share your
Records with another Role or Group that is in a di erent tree branch in the Role Hierarchy? Use
sharing rules.

Can be used when OWD is set to anything more restrictive than Public Read Write, otherwise
redundant
For example, if the OWD for Opportunity
Object is Private and Role Hierarchy is
applied, this means that only owner can
see his Opportunities and also his
manager through Role hierarchy.
What if you want to share your
Opportunities with another Role or Group that is in a di erent tree branch?
Role grants access is Vertical Sharing Rule can be Vertical or Horizontal
Sharing Rule can be based on Record Owner or Record Criteria that you
choose
Access Pro le through: Administer | Security Control | Sharing Settings
Sharing can be among any to any of: Roles, Roles and Subordinates, Public
Group, Manager Group, Manager Subordinates Group
Or it can be by Record criteria to be shared with one of the above
You can specify the sharing access level: Read Only, or Read/Write

Manual Sharing

6- What if you want to share your Record with another 1 user,

without the need of creating a Sharing Rule? You use Manual
Sharing.

Manual sharing is through a button on the Record page

The button should be added to the Page Layout
The button will appear if the OWD is more restrictive than “Public Read Write” because if it were “Public Read
Write”, there is no need to share as it is already shared with all users Read and Write
To share, go to the Record that you want to share and click on Sharing

How the layers works so far: Baseline Pro le Permissions, OWD, Role, Sharing Rules, Manual Sharing

Video 6: Field level security (FLS)

Your Salesforce org contains a lot of data, but you probably don’t want every eld accessible to everyone. For
example, your payroll manager probably wants to keep salary elds accessible only to select employees. Individual
Fields should only be seen to certain pro les –
FIELD LEVEL SECURITY

It allows to Grant or Restrict eld visibility

based on user pro le
Available in Enterprise, Unlimited, Performance, and Developer Editions only.
Restrict users’ access to view and edit elds on detail and edit pages.

Custom Field example: Max budget:

Edit to go to eld settings

If make it Required, then you cannot make it invisible

1- Field Level Security (FLS):

FLS overrides both the Modify All Data and View all Data
user permissions (part of the System Admin pro le)
To set eld FLS, go to the Object (custom or standard), then
Field – click on the “Set Field Level Security” button on the
top of the Field properties

The FLS on the right, is the exact same FLS you access when you go to the Pro le in question
Can also access FLS from Pro le itself

2- Page Layout Visibility:

Con gured on the Page layout for each eld

Field can be Read-Only or Required

1 and 2 – Field Accessibility:

Field Accessibilty is the summary of what eld access each Pro le has
on the eld in question (FLS + Layout)
2 ways to access Field Accessibility:
1- In the eld page You can
click on “Field Accessibility” to
get the full page containing both FLS and Layout options
2- You can also go to ALL Field Accessibility of All Objects by: Administer | Security Controls |
Field Accessibility. Advantage of this: can be by Field or by Pro le

Note: FLS override any less-restrictive eld access settings in

layouts: For example, if a eld is required in the page layout and
read only in the eld-level security settings, the eld-level
security overrides the page layout and the eld will be read only
for the user.

Video 7: User Sharing

Share a single user record with individual users, personal or public

groups, the users in a particular role, or the users in a particular role plus
all of the users in roles below that role

For instance when 1 or more of your users need access to all other
user records – for example HR and Finance need access to all user
records
Overrides OWD and sharing for user object only
To share a single user with another group, go to the User record | click on the Sharing button | add the user or
group that this user is shared with
Individual sharing can only be used to grant wider access to data, not to restrict access.
If you want to grant a pro le to see all users, you can do it in the Pro le permissions, or Permission Set for 1 user

Video 8: Permission Sets

What if 1 user needs access to additional permissions and settings than what his pro le has? Use Permission Sets
Permission set is just like a Pro le, but it is applied to 1 user only. This way you don’t need to create too many pro les,
just Permission Sets for the special users. This will grant access to these users only.

Whereas the pro le is used to set the foundation for a user’s privileges, permission sets are optionally used to
extend a user’s privileges.
Extends the user’s access and permissions
Contains many of the settings found in Pro les
Access it via:
Administer | Manage Users | Permission Sets
Create and name a PS.
PS has 2 sections: Apps and System Settings (same as the Pro le permission page)
Add the rules you want, for example, Delete Leads (Object Permission) and Transfer
Leads (App permission)
Finally Assign it to the user: click on Manage Assignment, and add the user you want
this PS applied on
you can also add Permission Set to a user by going on the User page and scrolling down to permission set
section and ADD

Video 9: Record Types

Check the Record Types chapter in “5- Standards and Custom Objects”

Notes:

Object Security: What actions a user can take on the records of a particular object (in conjunction with record
security).
Record Security: What actions a user can take on an existing record (in conjunction with object security).
Field-Level Security: Determines which elds a user can view and update for each object.
Folder Security: Determines access to a variety of information including reports, dashboards, email templates,
and more.
To delete a record, the user must have the “Delete” object permission (pro le or permission set) and “Full Access”
to the record. “Full Access” is typically granted to the record owner, users higher in the role hierarchy than the
record owner, and system administrators.

4.2- Describe the features and capabilities of the Salesforce sharing model (e.g., record ownership,
organization-wide defaults, roles and the role hierarchy, manual sharing, sharing rules and public groups)
Sharing is to grant Record Access (Record level security)

Sharing Models:

Sharing rules: What if you want to share your Records with another Role or Group that is in a di erent tree
branch in the Role Hierarchy? Use Sharing Rules.
Manual Sharing: What if you want to share your Record with another 1 user, without the need of creating a
Sharing Rule? You use Manual Sharing.
User sharing: Share a single user record with individual users, personal or public groups, the users in a particular
role, or the users in a particular role plus all of the users in roles below that role
Note: How to share record visibility based on eld value? Set the Organization Wide Defaults to Private and then
use Criteria based Sharing Rules to open up access to records based on eld values
How to share a single user records with another? Use Sharing Rule with Groups presenting the user(s)

Groups:

Public groups are used to streamline the process of sharing access to records and folders.
A group is comprised of users, roles, and other groups.
Group Types:
Public Groups: created by admins, can be referenced in org-wide con guration (such as sharing rules. Note
that Sharing Rules cannot share individual user records with another individual user. For that you should
create Groups that represent 1 or 2 users to use Sharing Rules with).
Personal Groups are created by users, and can only be referenced in select con guration (such as Outlook
contact synchronization).
Use Cases:
Sharing access to records or folders with named users (this requires a public group) – For example haring
Rules applies to Roles and Groups, not users!
Sharing access to multiple Roles at the same time
There is no way to monitor where groups are referenced (e.g. you have to view each individual report folder,
sharing rules, etc.). For this reason, make sure to have a clear documentation and usage strategy for groups (or
at a minimum, a very clear naming convention).
When groups are referenced in sharing rules, “Grant Access Using Hierarchies” can be extended to group access.

Manager Groups:

Manager Groups allow you to Share a Record with your manager and his managers chain. Manager Subordinates
Groups will allow you to share the record with all uses in tree hierarchy under your Manager (might be more than one
role).

Manager Groups is disabled by default, but can be easily enabled by Admin

As admin, you can enable Manager Groups from Setup | Security Controls | Sharing Settings, look for
Organization-Wide Defaults and click Edit button, scroll down to Other Settings and select Manager Groups and
then click Save.

When Manager Groups sharing setting is enabled, user can manually share a record to Manager Group and
Manager Subordinates Group by click “Sharing” button from any page layout, additional option Manager Groups
and Manager Subordinates Groups will be available on top of current option.

4.3- Given a scenario, apply the appropriate security controls (e.g., organization-wide defaults, roles and the
role hierarchy, manual sharing, sharing rules and public groups)
Who is the most restricted user of this object? Standard employee.
Is there ever going to be an instance of this object that this user shouldn’t be allowed to see?
Yes – Sharing model is Private
Is there ever going to be an instance of this object that this user shouldn’t be allowed to edit?
Yes – Sharing model is Public Read Only
No – Sharing model is Public Read/Write

4.4- Describe the various settings and permissions a pro le controls (e.g., IP access, login hours, record
types, access to tabs, permissions, object permissions, eld-level security)
Pro les controls:

Which standard and custom Apps users can view? Which is

the default App?
Permissions per Object that allow users to create, read, edit, and delete records
Which Object tabs users can view?
Which page layouts users see?
Which record types are available to users? (for example, in Cases, Internal and External)
Which elds within objects users can view and edit

Permissions per App:

Custom Permission for the Pro le:

Admin Permissions that allow users to manage the system and apps within it
Which Apex classes and Visualforce pages users can access
Which desktop clients users can access
The hours during which and IP addresses from which users can log in (Login hours, Login IP)
Which service provider’s users can access (if Salesforce is enabled as an identity provider)

4.5- Given a scenario, determine the appropriate use of a custom pro le

A pro le is a collection of permissions and other settings associated with a user or a group of users. Your
organization has a number of standard pro les already de ned. If you create a custom object, the permissions to
access that object (“Read,” “Create,” “Edit,” and “Delete”) are disabled for most pro les. This security setting
ensures that access to custom objects and their data is only explicitly granted to users. You can change these
permissions in custom pro les, but not standard pro les. You should clone the standard Pro les and edit the
clone.

4.6- Extra Notes
Delegated Administration:

Delegated administration allows named users to manage other

users within selected roles and pro les, as well as manage elds
on selected custom objects. Why? If you give full Admin privileges
to any user = Danger!
Delegated admin allows you to specify which users (based on
role/pro le) and custom objects (standard objects excluded) a
delegated administrator can manage.
Use delegated admin to assign limited administrative privileges to
users who aren’t administrators. For example, make the
Customer Support team manager a delegated administrator to
manage users in the Support Manager role and all subordinate
roles.
Create it: go to Administer | Security Controls | Delegated
Administration
Give a name for the “Delegated Group Name”
You can check the box “Enable Group for Login Access” to allow
the group’s delegated Admin to Login As
We just created a delegated group! Now add details, such as
which users are delegated administrators for the group. Click the
info bubbles in the related lists to learn about the attributes you
can add:
Delegated Admins (DA): assigned delegated
Admins
User Administration: DA can create and edit and reset pass
for these roles and subordinates
Assignable Pro les, Permission Sets (PS) and Public
Groups: DA can assign these pro les, PS and Groups to
the users he can administer
Custom Obj. Permission: which objects and tabs admin can administer

Custom Permissions

Custom permissions can be used to de ne permissions within a custom application or process.

For example, your organization has implemented a custom application in Salesforce to track leave requests. One
of the buttons in the application invokes a custom process (apex/VisualForce code) to mass approve leave
requests.
Previously, if a developer wanted to de ne a permission to mass approve leave requests, this was often
con gured through the use of a custom eld on the user object (e.g. checkbox “Can Mass Approve Leave
Requests”) or via the use of a hierarchy-based custom setting. Both of these approaches have limitations.
With custom permissions, a developer can de ne a permission to represent the user’s ability to mass approve
leave requests. This custom permission can then be assigned through the use of a pro le or permission set, like
any standard Salesforce permission.
Creating and de ning custom permissions would be performed by a developer. However, administrators should
be aware of custom permissions and the potential security implications when used.

Single Sign-On:

Single Sign-On provides the capability for a user to login to one system and have access to one more additional
systems facilitated systematically as a result. For example, a user may authenticate to their network through
Active Directory (Microsoft Windows) and thereby be granted access to Salesforce.com without providing a
username and password.

Setting up the App Launcher

The Salesforce App Launcher is a single sign-on portal, allowing users to launch both
Salesforce and external applications Connected Apps (external apps via single sign-on).
When I click on the Apps (external), I get SSO logged in
Pro le or Permission Set for the user:
Add the allowed Apps in the “Assigned Connected Apps” permission
“Use Identity Features” (Gives the user access to Identity features such as App
Launcher.
Enable the App Launcher App (make it Visible for this Pro le)
Order of Apps in Setup | Manage Apps | App Menu
Manage Connected Apps in Setup | Manage Apps | Connected App (you should install
Apps rst and do:
Connected App needs a Start Url: copy the IdP initiated URL and make it the start
URL
Add Pro le to the App: Manage Pro le – select the Pro le – Save
Check: https://www.youtube.com/embed/WDElVK9SXjA

Monitor Salesforce instances:

Use trust.salesforce.com to monitor system and security status, as

well nd best practices from Salesforce.

6 Comments

Ofer Doron
October 24, 2016 at 12:18 pm

Note: FLS override any less-restrictive eld access settings in layouts: For example, if a eld is required in the page layout and read only
in the eld-level security settings, the eld-level security overrides the page layout and the eld will be read only for the user.

I think it’s wrong. I set a layout’s eld as required, then I changed it’s eld level security to read only, and once I used the layout – I could
edit the eld.

Ofer Doron
October 24, 2016 at 12:48 pm

Sorry about the previous post, please ignore it. The reason for my mistake was that I used the administrator pro le, which has the
permission “edit read only elds”….

Sean
November 16, 2017 at 2:36 am

There is org wide trusted IP range but there is also pro le level IP range. If both are set how does it work?

Ibrahim
March 6, 2018 at 4:08 pm

Sean, when the two levels are set, the pro le level applies.

Hania
April 6, 2018 at 8:06 pm

@sean, if only the IP range in Org-wide is set, the users will asked to verify their key ( email will be sent to them) however if the IP range
from Pro le level is set, users cannot work outside this range.

Gehirndoping | Nootropika & Biohacking

September 4, 2018 at 10:31 am

Excellent blog! Do you have any helpful hints for aspiring

writers? I’m hoping to start my own site soon but I’m a little lost on everything.

Would you suggest starting with a free platform like WordPress or go for
a paid option? There are so many options out there that I’m totally overwhelmed ..
Any recommendations? Thanks!

Leave a comment
Your email address will not be published.

Name

Email

Website

Post Comment

Powered by WordPress / Academica WordPress Theme by WPZOOM