News & Resources — Tips & Tricks

The Salesforce Security Model, aka “Who can see what in Salesforce?”

Posted by David Solsberry, Senior Consultant

A justifiable fear of setting up a Salesforce organization involves the practice of making sure Salesforce users are viewing information that they are entitled to view.  The Salesforce Security Model is followed to ensure there are no such “loopholes” through which users can slip through, thus inadvertently having access to information they are not supposed to “see.”

There are four “tiers,” or levels, that make up the Salesforce Security Model:

  • Organization Security
  • Object Security
  • Record Security
  • Field Security

A good rule of thumb in viewing these security levels is that the top level — Organization Security — carries the most general — or “global” — restrictions, while the restrictions become more granular (or detailed) as you move down to each level in the model.

Organization Security

At the organizational security level, general, broad rules are set to establish when — and from where — a user can access the system.

The first organizational security setting is Trusted IP Ranges.

Trusted IP Ranges can:

  • Limit your users to log in only when they are in the office. If a user logs in from an IP address within the specified range you set, they will gain access to your organization without issue.
  • If a user attempts to log in from outside the trusted IP range, he or she will be asked to enter in a code sent to their mobile device.
  • This prevents unwanted access, but it still provides users, such as sales representatives, access when they are working from the road, where the user’s IP addresses change frequently.

IP-related restrictions can also be placed on individual User Profiles.  When IP Ranges are specified on the user’s profile, however, those who attempt to log in from outside the trusted IP range will not receive a verification code on their mobile device; they will be denied access instead.

Another useful organizational security setting is Login Hours. Log-in hours specify when a user can (and cannot) access the Salesforce instance.  This is especially useful in situations where the organization does not want users to access Salesforce on weekends, or after a particular time in the evening or early morning.

Object Security

Object-level permissions determine what actions (Create, Read, Edit, Delete) a user can perform on standard or custom object records.

  • In order to view an object’s records, the “Read” object-level permission is required.
  • To create a new record for a specified object, the “Create” object-level permission is required.
  • In order to edit or delete an existing record, the user first needs to be assigned the pertinent object-level permissions and record-level permissions as displayed in the following example:

Record Security

Once a user has been granted the ability to Create, Read, Edit or Delete a record within an assigned object, however, this does not mean the user can do so at will.  This is where record-level security comes in.  Record-level security serves to specify exactly which existing records can be viewed or edited.  Records are “owned” by specific users — usually the user who created the record — so a user who does not own the record does not have the ability to change or delete another user’s record without additional permissions.

There are 3 levels of record-level permissions:

  • Read Only
  • Read/Write
  • Full Access

The most common methods of granting “Read Only” and “Read/Write” access to a user are through organization-wide defaults and sharing rules.  Users with the object-level permission “View All” are granted “Read Only” record-level permissions to all records of a particular object in the previous section, Object-Level Security.

So what entails “full access” to a record, where the user can do more than just view a record?  In order to explain, a brief introduction to Roles is required.

For the purpose of understanding record-level permissions, a good rule of thumb in understanding a role hierarchy is to picture a traditional organizational chart, as illustrated below:

  1. Chief Operating Officer
    1. Company President
      1. Manager
        1. Customer Service Representative

“Full Access” to a record is granted to:

  • The record’s owner.
  • Users higher in the role hierarchy than the record owner.
    • In the role hierarchy/organizational chart above, this means that if the Manager owns the record, the Company President and Chief Operating Officer will have full access to the record in question. The Customer Service Representative will not.
    • This is always applicable when the setting “Grant Access Using Hierarchies” is enabled on the object in question. This setting is automatically enabled for standard objects, but must be specified for custom objects.
  • Users with “Modify All” object-level permission, as illustrated above in the Object Security section (this includes system administrators).

Field-Level Security

Field-level permissions determine what — if any — specific fields a user can view and/or edit on an object record.  Field-level permissions have 2 settings:

  • Visible
  • Read-Only

Following is the combination of settings:

  1. If you wish to make the field editable to non-owners of the record:
    • Visible is checked.
    • Read-Only is unchecked.
  2. If you wish to make the field read-only:
    • Visible is checked.
    • Read-Only is checked.
  3. If you wish to hide the field:
    • Visible is unchecked.
    • Read-Only is unchecked.

One final note: a user must be able to view the record (as specified in the “Record Security” section above) in order to view any fields on the record.  Likewise, if a user cannot edit a record, they will not be able to edit any fields within that record.


Posted in Tips & Tricks