preloder

Who Sees What: Data Visibility How to Series

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”

Feedback:

Notify of