Salesforce Security: Concepts

Salesforce Security Layers

1. Organization: Login IP ranges, Login hours; when where how can a user login to the org
2. Object: Object-level security; what action can a user have on a specific object
3. Field: Field-level security; what field can a user read/edit
4. Record: Sharing; what records can a user access

From an architect’s perspective, data access in Salesforce falls into 2 main categories:

• Object-level access, which includes field-level access
• Record-level access

Profiles and Permission Sets determine the object level security access to each object in Salesforce.

Read object-level security doesn't give Read access to all account records, it only gives the ability to read account records.

Profiles

A profile contains the baseline permissions of a user, and each user is assigned only 1 profile. It defines a user’s ability to peform different functions, access records, and the way the records are displayed. Profiles are tied to a user license.

Enhanced profile user interface lets you search for any setting and it can take you to this setting page. This can be set up in Setup —> User Management Settings.

Permission Set

A permission set is a collection of permissions that can be assigned to a user extending users’ functional access without changing their profiles. Users can have only one profile but they can have multiple permission sets.

Permission Set Group (PSG): It is a collection of permission sets. Users with a PSG receive the combined permissions of all the permission sets in the group. You can also remove individual permissions from a group with the muting feature, to further customize the group. Please note that a PSG can only contain 1 muting permission set that is created within the group.

A profile doesn’t provide the appropriate mechanism for scalable permission assignment. Permission sets and PSG are used to avoid the creation of many different profiles that are only slightly different.

List of permissions that are missing in a permission set

• Page layout assignment
• Login hours and Login IP ranges
• Desktop client access
• Session settings
• Password policies
• Delegated Authentication
• 2-factor authentication with SSO
• Organization-wide email addresses are assignable by profiles only
• Default record type per object
• Profile specific search layouts

Record Ownership

Every record must be owned by a single user or queue. The owner has access to the record, based on the object settings of the owner’s profile. Queue members and users higher in a role hierarchy can access queues from list views and take ownership of records in a queue.

Record ownership and full access are synonymous and interchangeable and provide the user with the highest level of access to a record.

Sharing (record-level access)

Record-level access determines which records a user can see for a specific object. Object-level security should allow to access this record.

• Organization-Wide Defaults
• Role Hierarchy
• Sharing Rules
• Manual Sharing
• Team Sharing
• Territory Hierarchy Access

For each object, the View All and Modify All permissions ignore sharing rules and settings.

View All Data and Modify All Data administrative permissions apply to all objects’ records.

Organization-wide Defaults (OWD)

OWD sharing settings specify the default level of access users have to each others’ records. OWD are the only way to restrict record access. You use OWD settings to lock down your data to the most restrictive level, and then use other sharing tools to selectively give access to other users. For each object, the OWD can be:

• Private
• Public read only
• Public read/write
• Public read/write/transfer: available for cases and leads
• Public full access: available for campaigns
• Controlled by parent

Role Hierarchy

Users can access the data of all the users directly below them in the hierarchy (subordinates) using the Grant Access Using Hierachies option. Managers gain as much access as their subordinates. This access applies to records owned by users, as well as records shared with them.

Public Group

A public group is a collection of individual users, roles, territories, and so on, that all have a function in common.

Groups can be nested (group A nested into group B), but keep in mind that nesting has an impact on group maintenance and performance due to group membership calculation. Don’t nest more than 5 levels. As a best practice, keep the total number of public groups for an organization to 100,000.

Sharing Rules

They allow for exceptions to OWD settings and the role hierarchy that give additional users access to records they don’t own. There are 2 types of sharing rules:

1. Ownership-based: records are shared following criteria based on their owner. For example, share all opportunities owned by user A with Group B. As a best practice, keep the number of ownership-based rules per object to 1000.
2. Criteria-based: they provide access to records based on the record’s field values.

Manual Sharing

Gives user the flexibility to share specific records with users that need to see them. To grant access to a record, you must be one of the following users:

• The record owner
• A user in a role above in the hierarchy
• Any user granted Full Access to the record
• An administrator

Team Sharing

For accounts, opportunities and cases, record owners can use teams to allow other users access to their records. The record owner adds team members and specifies the level of access each team member has to the record, so that some team members can have read-only access and others can have read-write access. The record owner can also specify a role for each team member.