- 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
Security and Access
In this module you will learn the following:
- How Salesforce classifies and evaluates security
- How to determine what permissions are required to complete an action
- How role, profile, and permission sets influence a user’s access
- How organization-wide defaults and the role hierarchy influence record access
- How to use delegated administration to enable power users to complete common administrative tasks
Module Progression
Please login to view your progression.
Priority
Objective
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.
Resource
Priority
Type
Length
Security at all applicable levels is required in order to complete an action.
For example, in order to create a lead record, a user must authenticate (organization security) and must have create access to the lead object (object security). Field-level security will then determine which fields the user can view and modify.
All actions require an active session (organization security allowed), and:
- Create a record: Create on Object, Edit on Field
- View a record: Read on Object, Read on Record, Read on Field
- Edit a record: Edit on Object, Read/Write on Record, Edit on Field
- Delete a record: Delete on Object, Full Access on Record
Resource
Priority
Type
Length
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.
Resource
Priority
Type
Length
The Enhanced Profile User Interface user interface setting changes the profile screen used by system administrators (enhanced vs classic). The classic profile page has user and object permissions on one page, while the enhanced profile page has a handy search bar.
Resource
Priority
Type
Length
Ensure that you understand the Salesforce license standard profiles:
- Contract Manager
- Marketing User
- Read Only
- Solution Manager
- Standard User
- System Administrator
Resource
Priority
Type
Length
As modification of standard profiles is limited, it is recommended to create custom profiles and assign users to those custom profiles.
One exception to this is the System Administrator profile which has highly elevated permissions and should only be assigned to administrators.
Resource
Priority
Type
Length
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).
Resource
Priority
Type
Length
See “Who Sees What: Permission Sets”
Note which permissions can be assigned by profile only, and which can be assigned by either profile or permission set.
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.
Resource
Priority
Type
Length
See “Who Sees What: Organization Access”
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
Resource
Priority
Type
Length
See “Who Sees What: Org-Wide Defaults”
The sharing button will appear (in Salesforce Classic only) when added to the page layout and the Org-Wide Defaults for the object are set to Private or Public Read Only.
This button can be used to determine who has what level of access to a record. The default view shows the grants providing access to the record, while the expanded view shows all users provided access.
In addition, users with Full Access to a record can manually share access to the record.
Resource
Priority
Type
Length
Objective:
A user’s role sets the foundation for what records they can access.
Users are granted Full Access to records to records that they own, as well as records owned by owned by users in subordinate roles on objects where Grant Access Using Hierarchies is enabled.
Grant Access Using Hierarchies is always enabled for standard objects but can be disabled for custom objects.
Resource
Priority
Type
Length
The role hierarchy provides a framework to structure access to records and other information in your organization. Various settings (sharing rules, groups, folder sharing criteria, etc.) rely heavily on roles to structure access to content.
It often helps to evaluate an org chart provided by human resources in order to create the role hierarchy structure in Salesforce. However, the role hierarchy in Salesforce must be designed based on access requirements and may ultimately vary significantly from an org chart provided by human resources.
Three examples provided by Salesforce are:
Resource
Priority
Type
Length
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.
Resource
Priority
Type
Length
See “Who Sees What: Record Access Via Roles”
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.
Resource
Priority
Type
Length
See “Who Sees What: Record Access Via Sharing Rules”
Objective:
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.
Personal groups are created and maintained by users, and can only be referenced in select configuration (such as Outlook contact synchronization).
Resource
Priority
Type
Length
When Grant Access Using Hierarchies is selected in a Public Group and that group is the target (Shared With) in a sharing rule, record access granted via the sharing rule will also be inherited via the role hierarchy.
For example:
- A sharing rule provides read only access to accounts owned by the role and subordinate roles of SVP, Sales & Marketing to the public group International Support.
- The public group International Support contains the role Customer Support, International. Members of this group gain read access to accounts owned by users in the SVP, Sales and Marketing or subordinate roles.
- Users in the role SVP, Customer Service and Support gain access to records owned by users in the SVP, Sales and Marketing or subordinate roles through Grant Access Using Hierarchies with the group configuration.
Note: Grant Access Using Hierarchies is only effective when the sharing rule is targeting a group (not when the group is the source of records).
Resource
Priority
Type
Length
Example
ARVE Error: API endpoint returned a 403 error. This can occur when a video has embedding disabled or restricted to certain domains.
Objective:
Ensure that you understand the fundamentals of queues – see User Setup for more.
When a user is a member of a queue and a record is owned by that queue, then the user will inherit Full Access to that record.
Visibility to many areas of Salesforce can be configured based on role and public group membership. For example, the sharing settings for a list view are similar to other areas of Salesforce, including email template folders.
This is an important consideration for those elements that are not directly aligned to organization, object, record, or field security.
Objective:
In order to change the record owner in Salesforce, you need either:
- Edit access to the record and the appropriate transfer permission.
- Full access to the record.
There are 3 transfer permissions:
- Transfer Lead (required for leads)
- Transfer Case (required for cases)
- Transfer Record (required for all other objects)
The Org-Wide Default for the Lead and Case objects can be set to Public Read/Write/Transfer, which removes the need for the Transfer Lead or Transfer Case permission.
To transfer a record to another user, the user being assigned the record must have read access to the object (you cannot transfer a record to a user that cannot then view the record).
Resource
Priority
Type
Length
Whereas profiles and permission sets grant full system administration rights, delegated administration allows for administration of a subset of users, permission set assignments, public groups, and objects.
This feature is designed to enable departments within organizations to maintain their own users without requiring full administrative capabilities.
Resource
Priority
Type
Length
There are administrative permissions for View All Data and Modify All Data that are assigned via profile or permission set. View All Data will grant read access to all objects and records (ability to see all data in Salesforce). Modify All Data will grant create, read, edit, and delete to all objects as well as full access to all records (ability to edit and delete all data in Salesforce).
View All and Modify All can also be enabled on a per-object basis. View All grants read access to the object and read only access to all records within that object. Modify All grants create, read, edit, and delete access to the object and full access to records within that object.
Objective:
Thank you for taking the time to complete this module. Please review these final resources. We welcome your feedback on anything that can be done to improve this content.
Resource
Priority
Type
Length
Course Navigation:
Feedback:
Please select an objective or resources to provide feedback. You may also provide feedback on this module here: Security – Module Feedback