Security Model Flashcards

1
Q

True or False?

The role hierarchy can not grant a user more access than they have through their profile permissions

A

True

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

True or False?

The role hierarchy can only open up access to records. It cannot restrict record access to less than what is granted through the Org Wide Defaults (OWD).

A

True

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Do you need role hierarchy if you have full profile CRED and teh OWD is Public Read/Write?

A

No. With having CRED and the OWD at Public Read/Write, you have full access to view and edit all records. The Role Hierarchy can not give you any more access…you already have complete access.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

True or False?

Neither the role heirachy, nor the field level security can grant a user more access than they have through their baseline persmissions.

A

True.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Review Profile, OWD, Access via Role Hierarchy and Field Level Security Work

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

True or False?

Sharing Rules let us extend access to users in roles, public groups or territories regardless of their place in the role heirarchy.

A

True.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Where do you find the sharing Settings?

(hint: same as OWD’s)

A

Setup>Security Controls>Sharing Settings

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

True or False?

Permission Sets take you above and beyond profile settings so you can grant permissions and access to only the users who need it

A

True.

Permission Sets give you flexibility and control over user permissions and access settings.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

How do you naviagate to permission sets?

A

Setup>Manager Users>Permission Sets

After you create a permission set label and select the type of user license that will use the permission set, you are brought to the Permission Set Overview page. Here you will find Apps & System Permission Sets to assign connect to your label. Once added to your label, you then assign to a user or group of users, by either the Manage Assigment button at the top of the PS Overview page, or through each user’s detail profile page.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

User Sharing let’s you control Who sees Who.

User Visibility Settings allow you to overwrite the OWD for user records specifically for external users in your portal or community.

A

Setup>Security Controls>Sharing Settings>scroll down…User Sharing Rules>New

OR

Setup>Manage Users>Users>Select a User>Click the Sharing Button at the top>Add Sharing

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Record Types Control Three Things.

A
  1. Business Processes
  2. Page layouts
  3. Picklist values
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

What are Business Processes?

A

Are special picklist fields that capture the lifecycle of Opportunities, Cases, Solutions or Leads

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

What are page layouts?

A

Let you select and organize groups of fields related to an object.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

What are Picklists?

A

Picklist values are the lists of choices that you define when you create picklist field.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Things to watch out for using Record Types

A
  • Edit record type assignments in the Mangage Users | Profiles
  • Any records createed before record types must have a record type assigned retroactively. (you can use Data Loader to Assign Record Types)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Describe the capabilities of the User Sharing feature.

Who sees Who.

A

User Sharing allows an administrator to set the user object org-wide default (OWD) to private. This feature is enabled by default for orgs created after the Winter 14 Release. To enable this feature in an existing org, contact Salesforce.com suppor

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

**Organization Security **

Org-level permissions determines under what conditions a user can login to Salesforce.

What are A few key settings?

A
  • When users can login (Login Hours)
  • Where users can login from (Login IP Ranges)
  • How users can login (API, UI, etc.)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Object Security

Object-level permissions determines what actions a user can perform on records of each object.

What is CRED?

A

(Create, Read, Edit, Delete)

In order to create a record of that object type, the user only needs the “Create” object-level permission.

In order to perform an action on an existing record, the user needs the corresponding object-level permissions and record-level permissions (see below).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

**Record Security **

What are the 3 tiers of record-level permissions?

A
  • Read Only
  • Read/Write
  • Full Access

“Read Only” and “Read/Write” access can be granted through a variety of means (org-wide defaults, sharing rules, etc.). Users with the object-level permission “View All” (pictured unchecked above) are granted “Read Only” record-level permissions to all records of that object.

“Full Access” is granted to:

  1. The record owner.
  2. Users higher in the role hierarchy than the record owner (when “Grant Access Using Hierarchies” is enabled).
  3. Users with “Modify All” object-level permission (this includes system administrators).
  4. Members of a queue to all records owned by the queue.

It is not possible to share “Full Access” via sharing rules or other mechanisms at this time.

20
Q

Record-level and object-level permissions correspond as follows:

A

Creat Record View Record Edit Record Delete

RecordObject-level permission Create Read Edit Delete

Record-level permission N/A Read Only Read/Write Full Access

21
Q

Scenario 1: A user must have the ability to create a lead records.

Required permissions:

A

Required permissions:

“Create” object-level permission on Lead

22
Q

Required permissions:

Scenario: A user must be able to view an opportunity record owned by another user.

A

“Read” object-level permissions on Opportunity.

“Read Only” (or higher) record-level permissions on the record.

23
Q

Required permissions: Scenario:

A user must be able to edit an account record owned by another user.

A

“Edit” object-level permissions on Account.

“Read/Write” (or higher) record-level permissions on the record.

24
Q

Required permissions: Scenario:

A user must be able to delete an opportunity record owned by another user.

A

“Delete” object-level permissions on Opportunity.

“Full Access” record-level permissions on the record.

25
Q

“Full Access” is typically granted to:

A
  1. the record owner,
  2. users higher in the role hierarchy,
  3. and system administrators.

As shown in example 4 above, “Full Access” record-level permission and “Delete” object-level permission are required in order to delete a record.

This explains why some users may not be able to delete records, even when granted “Read/Write” record access via sharing rules or org-wide defaults.

Important Notes:

  • Not all objects will adhere exactly to the above rules (e.g. products, which do not have a record owner).
  • If a user can edit (but not delete) a record and has the “Transfer Record” permission, they may be able to transfer the record to become its owner. They may be able to then delete the record.
26
Q

Field-Level Security

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

A
  • Visible
  • Read-Only

The combination of settings are as follows:

RESULT VISIBLE READ-ONLY
Field Editable Checked Unchecked
Field Read-Only Checked Checked
Field Hidden Unchecked Unchecked

A user must be able to view the record in order to view any fields on the record. Likewise, if a user cannot edit a record, they will not be able to edit any fields.

Note: Page layouts also influence which fields a user can update within the User Interface, which is discussed in the future.

27
Q

Folder Security

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

A
  • Reports
  • Dashboards
  • Email Templates
  • Documents

You’ll see this similar mechanism used in many areas not specifically labeled as folders as well (such as list views):

28
Q

Security Overview

A

Key Facts:

  • Organization Security: When (Login Hours), where (Login IP Ranges), and how (UI/API/etc.) a user can login.
  • 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 fields 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.
29
Q

Explain who can delete records in Salesforce.

A

To delete a record, the user must have the “Delete” object permission (profile 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.

30
Q

What is a profile?

A

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
Org-Level Permissions
Object-Level Permissions
Field-Level Permissions
User Permissions

USER INTERFACE
Applications
Tabs
Page Layouts
Record Types

31
Q

What’s the difference between standard and custom profiles?

A

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

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

32
Q

When should I create custom profiles?

A

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.

33
Q

What are user permissions?

A

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” user permission can access any SalesforceAPI. You can enable user permissions in permission sets and profiles.

To view permissions and their descriptions, from Setup, click Manage Users | Permission Sets, then select or create a permission set. Then from the Permission Set Overview page, click App Permissions or System Permissions.

34
Q

List and describe the standard profiles.

A

Ensure that you understand the Salesforce license standard profiles:
Contract Manager
Marketing User
Read Only
Solution Manager
Standard User
System Administrator

35
Q

Contract Manager

A

Can create, edit, activate, and approve contracts. This profile can also delete contracts as long as they are not activated. Can edit personal quota and override forecasts.

36
Q

Marketing User

A

Can manage campaigns, import leads, create letterheads, create HTML email templates, manage public documents, and update campaign history via the import wizards. Also has access to the same functionality as the Standard User.

37
Q

Read Only User

A

Can view the organization’s setup, run and export reports, and view, but not edit, other records.

38
Q

Solution Manager

A

Can review and publish solutions. Also has access to the same functionality as the Standard User.

39
Q

Standard User

A

Can create and edit most major types of records, run reports, and view the organization’s setup. Can view, but not manage, campaigns. Can create, but not review, solutions. Can edit personal quota and override forecasts.

40
Q

System Administrator

A

Can configure and customize the application. Has access to all functionality that does not require an additional license. For example, administrators cannot manage campaigns unless they also have a Marketing User license. Can manage price books and products. Can edit any quota, override forecasts, and view any forecast.

41
Q

Explain when to create a custom profile.

A

As customization of standard profiles is limited, create custom profiles prior to assigning users to profiles.

42
Q

Describe permission sets, and common use cases where they are appropriate.

A

Key Concepts:

Whereas the profile is used to set the foundation for a user’s privileges, permission sets are optionally used to extend a user’s privileges.

Permission sets can drastically reduce the number of custom profiles required in an org.

Two common use cases:

  1. One-off cases where a user needs privileges not granted by their profile (e.g. extending the delete leads permission to one inside sales team, while the rest of the team cannot delete leads).
  2. Extending privileges to users that are assigned different profiles (e.g. access to a 3rd party application).
43
Q

Why use permission sets?

A

Using permission sets effectively can help you reduce the number of profiles needed in your Salesforce org, which can dramatically reduce administrative overhead in some scenarios.

44
Q

When is the use of permission sets appropriate?

A

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 instances where the same set of privileges must be granted for users that are assigned to different profiles (e.g. providing access to a 3rd party application shared by several departments).

Important Notes

  • 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.
45
Q

User Permissions and Access

Every user is assigned only one profile, but can also have multiple permission sets.

When determining access for your users, use profiles to assign the minimum permissions and access settings for specific groups of users. Then use permission sets to grant additional permissions as needed.

A

Not in Permission Sets (vs. profile):

  • Page layout assignments
  • Desktop client access
  • Login hours
  • Login IP ranges
46
Q

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

A

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.

The most commonly used settings are:

  • *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