- Describe how security is structured in Salesforce.com.
- Explain how to determine what security permissions are required in order to complete an action in Salesforce.com.
- Describe profiles and their influence on security.
- Describe the significance of the Enable Enhanced Profile User Interface setting.
- List and describe the standard Salesforce profiles.
- Explain when to create a custom profile in Salesforce.com.
- Describe permission sets, and common use cases where they are appropriate.
- Describe the settings an administrator controls to conditionally allow or prevent user authentication.
- Describe how Organization-Wide Defaults (OWDs) influence security.
- Describe how the sharing button can be used to monitor record access and facilitate manual record sharing in Salesforce.com.
- Describe the significance of a user’s role and Grant Access Using Hierarchies on record security.
- Given a scenario, determine how to properly structure the role hierarchy.
- Describe the impact of role configuration on accessing records related to an account (contacts, cases, opportunities).
- Describe sharing rules, and when their usage is appropriate.
- Describe the different types of groups available in Salesforce and when their use is appropriate.
- Describe when to select Grant Access Using Hierarchies when configuring a public group.
- Describe a queue’s influence on security.
- Describe how access to list views, documents, email templates, and similar information is secured in Salesforce.com.
- Describe the permissions required to transfer (change ownership) a record in Salesforce.com.
- Describe delegated administration, and when its usage would be appropriate.
- Describe the significance of the View All and Modify All permissions in Salesforce.com.
- Security – Module Checkpoint
Who Sees What: Data Visibility How to Series
Video
Must
50m
Salesforce.com
The “Who Sees What” series is a great introduction to Salesforce security.
Objectives for this Resource:
Security controls in Salesforce largely fit into one of the following classifications:
- 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.
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 on accounts also provide access to related contracts and can provide access to related Contacts, Opportunities, and Cases.
Sharing rules can extend either Read Only or Read/Write access, but cannot extend Full Access.
See “Who Sees What: Record Access Via Sharing Rules”
Login IP Ranges are used to prevent login except from specific IP addresses.
Login Hours are used to prevent login during certain hours of the day.
The permission (profile/permission set) API Enabled is required for a user to authenticate via the API.
See “Who Sees What: Organization Access”
When the org-wide default setting for contact, opportunity, or case is set to Public Read Only or Private, then you will be able to configure each role’s access to the respective object on accounts that they own.
For example, in a private sharing model, you can provide support personnel access to view all related cases to accounts that they own.
See “Who Sees What: Record Access Via Roles”
Each user is assigned one profile, which is instrumental in determining a user’s functional access (apps, tabs, object and field permissions), how information is displayed to the user (page layouts, record types, etc.), and a wide range of other permissions.
Organization-wide default settings determine the default record-level permissions granted to all users for all records within each object. For example, setting the Account object to “Public Read/Write” will ensure that all users have “Read/Write” record-level permissions to all account records.
- 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 (Only: Cases, Leads): Read/Write plus transfer (ability to change the record owner) permissions granted
- Controlled by Parents (Only: Contacts, Activities): Parent record controls access
- Public Full Access (Only: Campaigns): Read/Write/Delete access granted
See “Who Sees What: Org-Wide Defaults”
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).
See “Who Sees What: Permission Sets”
Course Navigation:
Feedback:
Certified On Demand © 2017. All Rights Reserved.
Salesforce is a trademark of salesforce.com, inc. Other names used herein may be trademarks of their respective owners.