4. Security and Access = 15%

How many Permission Sets can an administrator create in their Salesforce org?

1000

How does a Profile differ from a Role?

A Profile determines what users can do with records they have access to, for example, view or edit. A Role determines what individual records a user has access to.

What is a group?

A group is comprised of users, roles, and other groups. There are two types of groups: Public groups and personal groups. -Public groups are created and maintained by administrators, and can be referenced in org-wide configuration (such as sharing rules). -Personal groups are created and maintained by users, and can only be referenced in select configuration (such as Outlook contact synchronization).

What is a profile?

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.

Describe roles and their influence on security.

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.

Which 2 sharing rules are available in Enterprise edition and Unlimited edition only? a. Account. b. Contact. c. Opportunity. d. Case. e. Lead. f. Campaign. g. Custom.

All sharing rule options "c" (Opportunity) through "g" (Custom) require Enterprise or Unlimited edition. Only Account "a" and Contact "b" sharing rules come with other editions.

The inside sales team must have the ability to create and edit opportunities. Each user within the inside sales team must only be able to view records that they own (Inside Sales User A should not be able to view Inside Sales User B's opportunities). The outside sales team must have the ability to create and edit opportunities, and view opportunities owned by users within both the inside and outside sales teams. How should this be configured in Salesforce? (Select all that apply) A. Configure org-wide defaults for opportunity to read only. B.Configure org-wide defaults for opportunity to private. C.Create a sharing rule: prevent the inside sales team from viewing records owned by the outside sales team. D. Create a sharing rule: the outside sales team will be granted read access to opportunities owned by the inside sales team. E. Create a sharing rule: the outside sales team will be granted read access to opportunities owned by the outside sales team. F. Create two roles: one for the inside sales team and one for the outside sales team.

B. Configure org-wide defaults for opportunity to private. D. Create a sharing rule: the outside sales team will be granted read access to opportunities owned by the inside sales team. E. Create a sharing rule: the outside sales team will be granted read access to opportunities owned by the outside sales team. F. Create two roles: one for the inside sales team and one for the outside sales team.

How would you allow collaborative access to the accounts, contacts, contracts, opportunities, and cases of a US Sales Rep, and APAC Sales Rep, and an EMEA Sales Rep? a. By creating three account sharing rules to share records between the Sales Reps. b. By creating a public group for the three Sales Reps, and one account sharing rule to share the public group's records with itself. c. By changing organization-wide defaults for Accounts to Public Read/Write.

By creating a public group for the three Sales Reps, and one account sharing rule to share the public group's records with itself.

The marketing team, several (but not all) executive users, and several (but not all) users from sales ops should be granted the ability to access several list views and a report folder. As the Salesforce administrator, how would you structure access? A. Specify the named users and roles within the sharing criteria for each list view and the report folder. B. Create a new role, and assign each user to this role. Specify the role within the sharing criteria for each list view and the report folder. C. Create a new public group, and assign each user to this group. Specify the public group within the sharing criteria for each list view and the report folder. D. Create a new permission set, and assign each user to the permission set. Specify access to the list views and report folder within the permission set.

Create a new public group, and assign each user to this group. Specify the public group within the sharing criteria for each list view and the report folder.

What is Delegated Administration?

Delegated administration allows named users to manage other users within selected roles and profiles, as well as manage fields on selected custom objects.

Describe profiles and their influence on security.

Each user is assigned one profile, which 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.

What is the significance of a user's role?

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.

An administrator can assign only one additional Permission Set to a user. a. True b. False

False

You can use Contact Sharing rules in orgs where Territory Management and B2I (Person Account) is enabled a. True b. False

False

CRED refers to permissions of Create, Read, Edit, and Delete that can be set at the field level. a. True b. False

False. CRED is set at the Object level, not the Field level as noted in the statement.

Sharing rules grant additional record access to defined groups of users on a record-by-record basis. a. True b. False

False. Its on an object-by-object basis; not record-by-record.

An example of manual sharing includes adding a person to an account team or opportunity team. a. True b. False

False. Manual sharing is invoked when you click on the "Sharing" button at the top of a record.

Role hierarchies allow users to access records that are viewable by individuals below them or at their same level. Additionally, they will have the same level of access to the records as those below them. a. True b. False

False. Only supports access to records for individuals BELOW them in the hierarchy, not at the same level.

The operations team uses a field on account called "Delinquency Status" to indicate when an account is behind on payment. This field should be visible to only the following users: -The entire finance team. -All sales managers. -2 named users of the 75 sales reps. What is the best way to implement this scenario? A. Grant field-level visibility to the Delinquency Status field to the finance team, sales manager, and sales reps via role. B. Grant field-level visibility to the Delinquency Status field to the finance team, sales manager, and sales reps via permission set. C. Grant field-level visibility to the Delinquency Status field to the finance team, sales manager, and sales rep profiles. D. Grant field-level visibility to the Delinquency Status field to the finance team and sales manager profiles. Grant field-level visibility to the Delinquency Status field to the two sales reps via permission set.

Grant field-level visibility to the Delinquency Status field to the finance team and sales manager profiles. Grant field-level visibility to the Delinquency Status field to the two sales reps via permission set.

Why use Delegated Administration?

If you assign user administration privileges using profiles or permission sets, that user will gain the ability to administer most or all users and objects in your org. Delegated administration allows you to specify which users (based on role/profile) and custom objects (standard objects excluded) a delegated administrator can manage.

Julie and Jim are both sales reps in your organization, and are collaborating on an account "Squared Wireless". Jim currently owns the account, and Julie cannot view the record in Salesforce. Jim would like for Julie to have the ability to view and edit the "Squared Wireless" account record. All other accounts records owned by Jim should remain not visible to Julie. Account collaboration is rare within your organization. Julie and Jim are assigned the same role and profile. How can this be solved in Salesforce? A. Instruct Jim to manually share the account record. B. Create a criteria-based sharing rule to grant access to records as needed. C. Set the org-wide default for accounts to read only. D. Add Julie and Jim to a public group "Sales Collaboration". Create a sharing rule that grants members of "Sales Collaboration" read/write access to account records owned by users in "Sales Collaboration".

Instruct Jim to manually share the account record.

What level of access do object permissions set for users?

Object permissions determine the kinds of records users can view, create, edit or delete. It does NOT control access to individual records themselves

What does OWD stand for?

Organization-Wide Default

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

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.

IP Restrictions and Login Access are examples of permissions set at what level of the Salesforce structure? a. Organization b. Object c. Record d. Field

Organization.

What are Permission Sets used for and when would you use them?

Permission Sets are used to grant additional permissions to specific users on top of their normal profile permissions. With permission sets, you don't need to modify a users profile.

What is a permission set?

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

Organization Security/ Org-level:

Permissions determines under what conditions a user can login to Salesforce; - When users can login (Login Hours). - Where users can login from (Login IP Ranges). - How users can login (API, UI, etc.).

Customer service reps must be able to create cases, and edit cases that they own. However, they should not be able to view cases owned by any other users. Org-wide defaults for the case object must be set to which of the following? A. Public Read/Write. B. Public Read Only. C. Private. D. Not Visible.

Private

Describe groups and their influence on security.

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.

Describe sharing rules, and when their usage is appropriate.

Sharing rules are used to extend record access to users within specified roles or groups. Records can be shared either based on record owner (role, group) or record criteria (known as a criteria-based sharing rule; e.g. all accounts in state "OH"). Sharing rules can extend either Read Only or Read/Write access.

What's the difference between standard and custom profiles?

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.

What can an Administrator provide additional permissions to with Permission Sets?

Tab. User. Object. Field. Service Provider. Apex Class. Visual Force.

What do organization-wide defaults control?

The default level of access users have to records they do NOT own, in each object.

Who can manually share records?

The record owner, users above the record owner in the role hierarchy, and administrators can manually share records.

What does the role hierarchy control?

The role hierarchy lets you open up record access to users who may have been denied access by the organization-wide defaults. Users in higher roles inherit the special ownership privileges of all records owned by users in roles below them. Additionally, the role hierarchy appears at the top of opportunity reports, allowing users to drill down to data at different levels of the hierarchy.

What is the significance of the role hierarchy?

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.

How are the two "Shared With" portions of account rules different below? Rule 1 Shared With: Role: Customer Support Rep. Rule 2 Shared With: Role & Subordinates: Customer Support Manager. a. Rule 1 does not give account access to Customer Support Manager. b. There is no difference. c. Rule 1 gives more access than Rule 2. d. Rule 2 gives access to more roles than rule 1.

There is no difference. Both rules perform the same action, as any sharing rule granted to the Customer Support Rep role automatically rolls up to the Customer Support Manager role.

The org-wide defaults for opportunity are set to read only. A custom field Commission has been added to the opportunity. Each user should be able to view this field for records that they own, but not for records they do not own. How can this be accomplished using Salesforce security configuration? A. Set field-level security to read only on the Commission field for the appropriate profiles. B. Set field-level security to hidden on the Commission field for the appropriate profiles. C. Set field-level security to hidden on the Commission field for the appropriate profiles, and create sharing rules to grant access to users to view the Commission field on records they own. D. Set field-level security to hidden on the Commission field for the appropriate profiles, and create permission sets to grant access to users to view the Commission field on records they own. E. This scenario cannot be solved using only Salesforce security configuration.

This scenario cannot be solved using only Salesforce security configuration.

Explain who can delete records in Salesforce.

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.

Why are sharing rules used?

To grant additional record access to groups of users on an object-by-object basis, allowing you to create exceptions to the organization-wide defaults.

When would you choose to build a public group?

To simplify the creation of sharing rules when more than one sharing rule is required.

Login hours apply to specific profiles. a. True b. False

True

The Administrator and members of the sales team can create default sales teams that will be assigned to newly created accounts. a. True b. False

True

The Role Hierarchy can be used to open up data access to managers in a Private or Hybrid data sharing model in Salesforce, who may have been denied access by the organization wide defaults. a. True b. False

True

The same team role list is used in both account and sales teams. a. True b. False

True

Using the field-level security to hide a field from a user also hides the field from list views, search results, and reports a. True b. False

True

Why use public groups?

Use public groups to streamline the process of sharing access to records and folders with a collection of users.

When is the use of permission sets appropriate?

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** 1. Permission sets can only grant (not revoke) privileges. 2 Permission sets are optional, and a user can be assigned more than 1 permission set (a user is assigned zero to many permission sets). 3. The profile controls some elements (e.g. page layout assignment) that a permission set cannot influence

Describe the capabilities of the User Sharing feature.

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

Explain how manual sharing can be used to extend record access.

Users can manually share access to records that they own with other users, roles, and groups.

Users can be assigned more than one Role.

Users can only be assigned ONE roll. If you assign them to another role, they will no longer be assigned to their old role.

Why use permission sets?

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.

Describe a queue's influence on security.

When a user is a member of a queue and a record is owned by a queue, then the user will inherit "Full Access" to that record.

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

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).

Describe the core principles of the security model.

Who Sees What: Data Visibility How To's [Must / 52m / Salesforce.com] [Who Sees What: Organization Access repeated from User Setup & Login Process - Free] Copy Link: https://www.youtube.com/playlist?list=PL6747B4DAE356E17C&src_vid=5KLTcu02nfY&feature=iv&annotation_id=annotation_3297769117

Where can you configure field-level security?

You can configure field-level security when you create a new custom field, when you edit an existing field in Setup, or by editing a Profile. Field-level permissions determines which fields a user can view and edit on records of an object. Field-level permissions have 2 settings: Visible Read-Only

How can you restrict login access to an organization?

You can restrict access to an organization by specifying login hours or login IP ranges on user profiles.

When should I create custom profiles?

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.

"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.

Folder Security:

used to secure a variety of data within Salesforce, including but not limited to: Reports Dashboards Email Templates Documents

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

"Create" object-level permission on Lead.

Scenario: A user must be able to delete an opportunity record owned by another user. Required permissions:

"Delete" object-level permissions on Opportunity. "Full Access" record-level permissions on the record.

Scenario: A user must be able to edit an account record owned by another user. Required permissions:

"Edit" object-level permissions on Account. "Read/Write" (or higher) record-level permissions on the record.

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

"Read" object-level permissions on Opportunity. "Read Only" (or higher) record-level permissions on the record.

What are 2 examples of setting Organization access to Salesforce?

- Login Access. - IP Restrictions.

If a Sales user needs to view the Amount field on the opportunity record, what Org, Object, Record, and Field access would the Sales User need to have?

- Login access to the organization. - At least Read-access to the opportunity object. - At least Read-access to the specific opportunity records he/she needs to see. - At least Read-access to the opportunity amount field.

Object Security/ Object-level:

- Permissions determines what actions (Create, Read, Edit, Delete) a user can perform on records of each object. - 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.

3 tiers of record-level permissions:

- Read Only. - Read/Write. - Full Access.

"Full Access" is granted to:

- The 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 permission (this includes system administrators). - Members of a queue to all records owned by the queue

What 3 parameters must an Administrator specify when creating a sharing rule?

- Which records to share? (owned by certain users, or meeting certain criteria). - Who to share them with? (public groups, roles, roles & subordinates). - What level of access? (read-only, read-write).

Which objects are supported for creating Criteria-based Sharing Rules? (select all that apply) a. Account. b. Contact. c. Opportunity. d. Contract. e. Case. f. Leads. g. Assets. h. Custom.

-Accounts. -Contact. -Opportunity. -Case. -Custom.

What groups or individuals comprise Public Groups with regards to establishment of sharing rules in Salesforce?

-Individual users. -Other public groups. -Roles and subordinates. -Roles.

The organization-wide default is set to private. Phil Smith, the owner of the ABC Labs account, is a US Sales Rep reporting to the US Sales Director. The users in the US Sales Rep role can edit ALL opportunities associated with the accounts they own. Tim, an EMEA Sales Rep, owns an opportunity associated with the ABC Labs account. Identify the correct role access (Select all that apply) a. Phil can VIEW but cannot EDIT Tim's ABC Labs opportunity b. Time cannot VIEW or EDIT Phil's account c. Phil can VIEW and EDIT Tim's ABC Labs opportunity d. Tim can VIEW and EDIT Phil's account e. Tim can VIEW but cannot EDIT Phil's account.

-Phil can VIEW and EDIT Tim's ABC Labs opportunity. -Tim can VIEW but cannot EDIT Phil's account.

Accounts teams are used for the following reasons: (Select all that apply) a. Share roles with the sales team. b. Are used for collaborative account management. c. Are used for sharing and reporting purposes. d. Are used for splitting of account credit if needed.

-Share roles with the sales team. -Are used for collaborative account management. -Are used for sharing and reporting purposes.

List the 4 tools available to establish sharing rules in Salesforce. List them in order of granularity of sharing, with lowest level of granularity at the top and highest level of granularity at the bottom.

1. OWD (organization-wide defaults) 2. Role Hierarchy 3. Sharing Rules 4. Manual Sharing OWD is the farthest reaching, but has a very low level of granularity. You can only set permissions at the object level. Sharing rules and Manual Sharing have the highest level of granularity, with Manual the highest because you can establish sharing rules at the user and record level.