Salesforce Security

Front 1

What is the sharing model and what are its implications for record and field data?

Back 1

the sharing model helps determine the org wide default settings for objects

1. who is the most restricted user?
2. ever an instance of this object that user shouldn't see? (yes - private sharing model)
3. ever an instance of this object that user shouldn't edit? (yes - public read only, otherwise public read/write)

Hint 1

the most restricted user - 2 questions

Front 2

What kind of record/data access does "controlled by parent" allow?

Back 2

• org wide default for an object

• A user can perform an action (such as view, edit, or delete) on a contact based on whether he or she can perform that same action on the record associated with it.

Front 3

What kind of data access does "grant access by hierarchies" allow?

Back 3

managers and higher will have same levels of access as their employees for that object - if disabled they won't be able to access depending on org defaults

Front 4

Compare benefits of using profiles vs sharing rules for managing data access

Back 4

• sharing rules only add access, profiles can add or hide

• sharing rules add access when org default more restrictive than public read/write

Hint 4

2 benefits

Front 5

What tools are in place to manage portal/communities security settings?

Back 5

1. SAML - SSO for community users
2. Authentication Providers -FB, etc
3. Authentication Flows with OAuth - flow from custom branded apps to branded login

Hint 5

3 options

Front 6

How can record types be leveraged for data access/security?

Back 6

unique page layouts

Front 7

What is territory management?

Back 7

an account sharing system that grants access to accounts based on the characteristics of the accounts.

enables structure your Salesforce data and users the same way you structure your sales territories.

Front 8

How does territory management impact sharing rules, or visa versa?

Back 8

Your role hierarchy interacts with your org’s sharing model to determine exactly what information a user can see, given the sharing setting is selected to use hierarchies.

For forecasts, a user’s role always determines which information he or she can view, regardless of the sharing model.

in a Private sharing model, a user’s role determines his or her access to other users’ data.

in a Public Read/Write or Public Read Only org, users can view (and edit, for Public Read/Write) information of all other users, in addition to having access to the data of users below them in the hierarchy.

Front 9

when would you use permission sets?

Back 9

• to extend a user's functionality without changing the profile

• users can only have one profile but multiple permission sets
• granted to specific users without giving admin profile or one-off profile
• different data needed or relevant for different uses at different times (like when hiring)
• easily assigned and revoked as needed
• for users with standard profile, assign permission set for specialty areas

Hint 9

one and many

hiring manager

Shelly

Front 10

when would you use custom profiles?

Back 10

• when you need to modify any of the permissions for a standard profile

• clearly defined job function

Hint 10

in stone

Front 11

when would you use delegated administration?

Back 11

assign limited admin privileges to users in your org who aren’t administrators.

For example, let’s say you want the Customer Support team manager to manage users in the Support Manager role and all subordinate roles. Create a delegated admin for this purpose so that you can focus on other administration tasks.

To delegate administration of particular objects, use object permissions, such as “View All” and “Modify All,” instead.

Hint 11

call center employees

Front 12

What can you do at the org level for security?

Back 12

1. list of authorized users
2. password policies
3. limit login access by time
4. limit login access by location

Hint 12

4 options

Front 13

What does object level security provide?

Back 13

1. simplest way to manage which groups of users access specific types of data
2. CRED permissions

Hint 13

2 points

Front 14

What does field level security provide?

Back 14

1. view/hidden read only/edit (CRED)
2. restrict access to specific fields even if user can access object

Hint 14

granular, only half the permissions

Front 15

What are the ways you can manage record level access?

Back 15

1. org-wide defaults
2. role hierarchies
3. sharing rules
4. manual sharing

Hint 15

4 ways

Front 16

How do org-wide defaults help manage record level access?

Back 16

• defines default level of access users should have to records owned by other users

• lock down to most secure, then open with other tools

Hint 16

2 points, lock down

Front 17

How do role hierarchies help manage record level access?

Back 17

open up access to those higher in the hierarchy

Hint 17

open

Front 18

How do Sharing rules help manage record level access?

Back 18

• provide automatic exceptions to the org-wide defaults for groups of users
• for records users don't own or don't normally see
• only provide more access, can't be stricter than defaults

Hint 18

open, 3 points

Front 19

How does manual sharing help manage record level access?

Back 19

• user can share a record
• not automated but useful like for vacation coverage

Hint 19

vacation

Front 20

On what does a profile's functionality in an org depend?

Back 20

user's SF license type

Hint 20

licenses

Front 21

Compare and contrast use of page layouts vs field permissions to manage security

Back 21

both - control visibility of fields

layout - only on detail and edit pages

field

• in any part of the app, inclu:
• related lists
• list views
• reports
• search
• *when you need to guarantee a user does not have access to a field

Hint 21

when you need to make absolutely sure...SSN

Front 22

Explain field level security as it relates to the object

Back 22

1. the object defines edit for the field
2. the field level security can override including modify all data and view all data
3. "visible" on field level is only edit if that profile has edit for the object

Front 23

When object and record level permissions conflict, which wins?

Back 23

the more restrictive

Hint 23

conservative

Front 24

compare permissons to default org defaults regarding access

Back 24

• permissions determine baseline access to all records
• org wide defaults further restrict on records the user does not own
• org defaults can never grant more access than permissons

Hint 24

all records vs records not owned

Front 25

compare role hierarchies vs sharing rules in how they open access

Back 25

• hierarchies open access vertically
• sharing rules open access horizontally or vertically
• sharing rules extend access in roles, public groups or territories regardless of place in hierarchy

Hint 25

directional

Front 26

What determines the object baseline permissions for a user?

Back 26

1. profile
2. permission sets

Hint 26

2 items, if applicable

Front 27

What are the 3 components of a sharing rule?

Back 27

1. records - by user ownership or criteria
2. users - users, roles, roles & subs, public groups
3. access - read only or read/write

best to use only when users are easy to define in advance and don't change a lot

Hint 27

stability

Front 28

What are the benefits of territory management?

Back 28

1. use account criteria to expand a private sharing model.

1. Support for complex and frequently changed sales organization structures.
2. Support for transferring users between territories, with the option to retain opportunities.
3. Multiple forecasts per user, based on territory membership.
4. Territory-based sales reports.

Hint 28

5 benefits

Front 29

What can delegated admins do?

Back 29

1. Create and edit users in specified roles and all subordinate roles. User editing tasks include resetting passwords, setting quotas, creating default opportunity teams, and creating personal groups for those users
2. Unlock users
3. Assign users to specified profiles
4. Assign or remove permission sets
5. Create public groups and manage membership in specified public groups
6. Log in as a user who has granted login access
7. Manage custom objects and customize nearly every aspect of a custom object. However, a delegated admin can’t create or modify relationships on the object or set org-wide sharing defaults.
8. Administer users across all delegated groups to which the delegated admin is assigned

Hint 29

8 things

Front 30

5 areas where roles impact access

Back 30

Record access - role hierarchy

Reports - ability to drill down

Forecasts - forecast hierarchy auto-generated by role hierarchy

Folders - access

Knowledge - access