Security Overview

Question 1

How is Access to data and functionality structured in Salesforce?

Answer 1

Access is primarily composed of:
Organization Security
Object Security
Record Security
Field Security
Folder Security

Question 2

What is Organization Security?

Answer 2

Org-level permissions determines under what conditions a user can login to Salesforce, e.g.
Login Hours
Login IP Ranges
How Login Occurs (API, UI, etc.)

Question 3

What is Object Security?

Answer 3

Object-level permissions determines what actions (Create, Read, Edit, Delete) a user can perform on records of each Object.

Question 4

What is Record Security?

Answer 4

There are 3 tiers of record-level permissions:
Read Only
Read/Write
These two tiers are Granted thru a variety of means
(org-wide, sharing rules, etc.)

Full Access
Granted to:
-Record Owner
-Users higher in the role hierarchy than the record owner (when Grant Access Using Hierarchies is enabled).
-Users with Modify All object level permissions (including Admins).
-Members of a Queue to all records owned by the queue.

Question 5

What is Field-Level Security?

Answer 5

Field-level permissions determines which fields a user can view and edit on records of an object.
Field-level permissions have 2 settings:
-Read Access
-Edit Access

Question 6

What is Folder Security?

Answer 6

Folders are used to secure a variety of data within Salesforce, including but not limited to:

Reports
Dashboards
Email Templates
Documents

Question 7

Describe the capabilities of the User Sharing feature.

Answer 7

User Sharing allows an administrator to set the user object org-wide default (OWD) to private.

User Sharing enables you to show or hide an internal or external user from another user in your organization.
With User Sharing, you can:
• Assign the “View All Users” permission to users who need to see or interact with all users. This permission
is automatically enabled for users who have the “Manage Users” permission.
• Set the organization-wide default for user records to Private or Public Read Only.
• Create user sharing rules based on group membership or other criteria, such as username and whether
a user is active.
• Create manual shares to grant access to individual users or groups.
• Control the visibility of external users in customer or partner portals and communities.

Question 8

What is a profile?

Answer 8

A profile is a collection of permissions and settings that is instrumental in determining a user’s functional access (apps, tabs, object-level permissions), how information is displayed to the user (page layouts, record types, field-level security), and a wide range of other permissions. Each user must be assigned one profile.

Security/User Interface
Org-Level Permissions/Applications
Object-Level Permissions/Tabs
Field-Level Permissions/Page Layouts
User Permissions/Record Types

Question 9

What are User Permissions?

Answer 9

User Permissions specify what tasks users can perform and what features users can access. For example, users with the “View Setup and Configuration” permission can view Setup pages, and users with the “API Enabled” permission can access any Salesforce API.

Question 10

Where can User Permissions be enabled?

Answer 10

You can enable user permissions in permission sets and custom profiles. In permission sets and the enhanced profile user interface, these permissions—as well as their descriptions—are listed in the App Permissions or System Permissions pages. In the original profile user interface, user permissions are listed under Administrative Permissions and General User Permissions.

Question 11

What is the difference between Standard and Custom Profiles?

Answer 11

Standard Profiles are included with Salesforce. Object-level permissions and user permissions cannot be changed on these profiles and these profiles cannot be deleted.

Custom profiles are created by an Administrator an can be fully customized. Custom profiles can be deleted.

Question 12

When should I create custom profiles?

Answer 12

Generally speaking you’ll want to create custom profiles prior to assigning users to profiles. As you have limited ability to change standard profiles, it is generally a best practice to assign all users (with the exception of the system administrator) to custom profiles.

If users are assigned a standard profile and you later need to change their permissions (e.g. add read access to a custom object), you’d have to create a custom profile and then migrate all of those users to the custom profile.

Question 13

List and describe the standard profiles.

Answer 13

Contract Manager
Marketing User
Read Only
Solution Manager
Standard User
System Administrator

Question 14

What is a Permission Set?

Answer 14

Permission sets are optionally assigned to a user to grant them privileges in addition to their profile.

Question 15

Why use Permission Sets?

Answer 15

Using Permission Sets effectively can help you reduce the number of profiles needed in your SF Org, which can dramatically reduce administrative overhead in some scenarios.

Question 16

When is the use of Permission Sets appropriate?

Answer 16

Use the profile to set the foundation for a User’s privileges. Then use Permission Sets to grant additional privileges for one-off cases, or for instances where the same set of privileges must be granted for users that are assigned to different profiles.

Question 17

Describe the key elements of Permission Sets.

Answer 17

• Permission sets can only grant (not revoke) privileges.
• Permission sets are optional, and a user can be assigned more than 1 permission set (a user is assigned zero to many permission sets).
• The profile controls some elements (e.g. page layout assignment) that a permission set cannot influence.

Question 18

What areas of Salesforce CANNOT be influenced by a Permission Set?

Answer 18

Page Layouts, Desktop Client Acces, Login Hours, Login IP Ranges.

Question 19

Describe how Organization-Wide Defaults (OWDs) influence security.

Answer 19

Organization-wide default 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.

Question 20

What are the most commonly used Access Levels?

Answer 20

Private: No record access granted
Public Read Only: Read only record access granted
Public Read/Write: Read/Write record access granted
Public Read/Write/Transfer (Cases, Leads): Full record access granted
Controlled by Parents (Contacts, Activities): Parent record controls access

Question 21

Describe roles and their influence on security.

Answer 21

A user’s role sets the foundation for what records and folders they can access. Users are granted full access to records owned by users in subordinate roles on objects where “Grant Access Using Hierarchies” is enabled.

Question 22

What is the significance of the role hierarchy?

Answer 22

The role hierarchy provides a framework to structure access to records and folders in your organization. Various settings (sharing rules, groups, folder sharing criteria, etc.) rely heavily on roles to structure access to content. Grant access using hierarchies has a profound impact on record security, as we’ll explore below.

Question 23

What is the significance of a user’s role?

Answer 23

Each user is assigned one role, which sets the foundation for their access to records and folders.

While a user’s profile and permission sets determine if a user can run reports, their role will influence which report folders they can access.

Question 24

Describe public groups and their influence on security.

Answer 24

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.

Question 25

Describe manager groups and their influence on security.

Answer 25

Manager Groups are used to share access to records based on the user’s manager (specified via the manager field on user record).

Manager Groups is disabled by default, but can be easily enabled by the system administrator.