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.

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

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.

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.

Ensure that you understand the Salesforce license standard profiles:

• Contract Manager
• Marketing User
• Read Only
• Solution Manager
• Standard User
• System Administrator

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.

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

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.

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

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.

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.

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:

1. Territory-based
2. Product-based
3. Company Size-based

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.

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.

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

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:

1. 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.
2. 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.
3. 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).

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.

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

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.

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.

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.