Security Overview

This article provides an overview of how access to data and functionality is structured in Salesforce, which is primarily comprised of the following:

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

Organization Security

Org-level permissions determines under what conditions a user can login to Salesforce, and is explored in depth in [link id=242].  A few key settings are:

  • When users can login (Login Hours)
  • Where users can login from (Login IP Ranges)
  • How users can login (API, UI, etc.)

Object Security

Object-level permissions determines what actions (Create, Read, Edit, Delete) a user can perform on records of each object.

In order to create a record of that object type, the user only needs the “Create” object-level permission.

In order to perform an action on an existing record, the user needs the corresponding object-level permissions and record-level permissions (see below).

1-8-2013 3-45-42 PM

Record Security

There are 3 tiers of record-level permissions:

  • Read Only
  • Read/Write
  • Full Access

“Read Only” and “Read/Write” access can be granted through a variety of means (org-wide defaults, sharing rules, etc.).  Users with the object-level permission “View All” (pictured unchecked above) are granted “Read Only” record-level permissions to all records of that object.

“Full Access” is granted to:

  • The record owner.
  • Users higher in the role hierarchy than the record owner (when “Grant Access Using Hierarchies” is enabled).
  • Users with “Modify All” object-level permission (this includes system administrators).
  • Members of a queue to all records owned by the queue.

It is not possible to share “Full Access” via sharing rules or other mechanisms at this time.

Record-level and object-level permissions correspond as follows:

[table id=28 /]

[tabs style=”default”] [tab title=”Example 1″]Scenario:  A user must have the ability to create a lead records.

Required permissions:

“Create” object-level permission on Lead.[/tab] [tab title=”Example 2″]Scenario:  A user must be able to view an opportunity record owned by another user.

Required permissions:

“Read” object-level permissions on Opportunity.

“Read Only” (or higher) record-level permissions on the record.[/tab][tab title=”Example 3″]Scenario:  A user must be able to edit an account record owned by another user.

Required permissions:

“Edit” object-level permissions on Account.

“Read/Write” (or higher) record-level permissions on the record.[/tab][tab title=”Example 4″]Scenario:  A user must be able to delete an opportunity record owned by another user.

Required permissions:

“Delete” object-level permissions on Opportunity.

“Full Access” record-level permissions on the record.[/tab][/tabs]

Demystifying Record Deletion within Salesforce

“Full Access” is typically granted to the record owner, users higher in the role hierarchy, and system administrators.  As shown in example 4 above, “Full Access” record-level permission and “Delete” object-level permission are required in order to delete a record.

This explains why some users may not be able to delete records, even when granted “Read/Write” record access via sharing rules or org-wide defaults.

Important Notes:

  • Not all objects will adhere exactly to the above rules (e.g. products, which do not have a record owner).
  • If a user can edit (but not delete) a record and has the “Transfer Record” permission, they may be able to transfer the record to become its owner.  They may be able to then delete the record.

Field-Level Security

Field-level permissions determines which fields a user can view and edit on records of an object.  Field-level permissions have 2 settings:

  • Read Access
  • Edit Access

2016-08-25_13-46-03

The combination of settings are as follows (it is not possible to have Edit Access without Read Access):

[table id=42 /]

A user must be able to view the record 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.

Note:  Page layouts also influence which fields a user can update within the [link id=363], which is discussed in the future.

Folder Security

Folders are used to secure a variety of data within Salesforce, including but not limited to:

  • Reports
  • Dashboards
  • Email Templates
  • Documents

You’ll see this similar mechanism used in many areas not specifically labeled as folders as well (such as list views):

1-9-2013 1-30-59 PM

59 thoughts on “Security Overview”

  1. Hi John,

    In Summer ’16 for the Field-Level Security, the labels “Visible” and “Read-Only” have been replaced by “Read Access” and “Edit Access” (respectively): https://releasenotes.docs.salesforce.com/en-us/summer16/release-notes/rn_forcecom_custom_general.htm#rn_forcecom_custom_general

    Presumably this means that the new Edit Access label is the inverse of Read-Only: that is, if Read-Only was previously checked, then Edit Access would be unchecked, and vice versa?

    Thanks,

    Mark

      1. Yep agreed it makes more sense. One thing though if that second column (edit access) is indeed the inverse of read-only then I bet it will catch some people out when they need to select the opposite of what they used to in that “second column”.

      2. Doesnt OWD use terms like Private, Public Read, Public Read/Write instead of Read, Read/Write and Full access?
        I am confused!
        Also,
        1.If we edit Field level security via Profile/permissions sets we have options Read Access and Edit Access
        2.If we edit Field level security via Fields i.e. Object->fields->your Field->Set Field Level Security we have options of View and Read Only
        Why this difference in terminology?

        1. OWD sets the object access- read only, read/write, private.

          Object level security is defined with read, created, edit, delete access. Profile, permission sets.

          Record level security is similar to OWD but also includes full access.

          Field level security you can set read and edit access to the field- if you see “read only” that translates to read without edit, and “visible” translates to edit access (without read only checked).

  2. What’s the difference between visible and read only? For some reason in my head I’m associating both as the same thing. For a user to have read only access, must they have visibility as well? Sorry to inundate you with questions lately, I’ve been getting very serious with my studying as of lately.

    Thanks in advance!

  3. Hi John
    I am missing a more detailed explanation on how record access is set up by Sharing Rules. It is not immediately obvious from the explanations under “Record Access”. Also, “Full Access” really means “Read/Write” in SFDC terms.

    thanks!

    1. Full Access is read/write/delete/transfer while Read/Write is just read/write (no transfer/delete).

      Sharing rules extend record access in addition to what is offered by the OWD for that object and the role hierarchy. I would revisit the who sees what series, which may help as well.

  4. Hi John,

    I am struggling to wrap my head around how record level security comes into play. I have worked some scenarios in my dev org and I can’t seem to get the behavior I was hoping would solve my questions. Here is what I tried:

    OWD for accounts set to Read Only
    Object Permissions for User A set to Read, Create for accounts
    Result: User A can see all account records regardless of owner, can create accounts, and User A can share the records he/she owns.

    Next,
    OWD for accounts set to Read/Write
    Object Permissions for User A set to Read, Create for accounts
    Result: Same as above, but User A can’t share the record. I would have expected that with read/write, as the owner of a record, User A would have been able to edit and delete his/her own account records and only read other users’ records.

    What am I missing? Doesn’t the record owner have full access to their own records with read/write OWD settings? How would I restrict User A from editing records owned by another user while still being able to edit/delete his/her own records?

    Thanks!

    1. Might have just solved my own questions.

      In order for User A to edit his/her own records, regardless of the OWD settings, the object level permission has to be set to Edit. If OWD is set to read/write, then User A would be able to edit other users’ records.

      What hung me up was that even though the ‘Edit’ button on the account record page was available for records owned by other users (logged in as User A), I got the insufficient privileges message after trying to edit.

      Maybe another example above with the scenario of a user having the permission to edit his/her own record but not records owned by another user might be helpful.

      Cheers.

  5. Re: Field level security. If I go to Profile settings and then Object Settings and select an object (for example, Accounts), the checkbox columns for Field Permissions say “Read” and “Edit,” not “Visible” and “Read Only.” I know I’ve seen Visible and Read only somewhere in the Settings area, but I can’t find where!? What am I doing wrong?

  6. @John, what happens if you do the following –
    1. Read access at object level and Read/Write at Field level
    2. Edit access at object level and Read at Field level
    and other such configurations?

    Thanks.

  7. How do you GET to the folder security outlined above? Is it only available when a role hierarchy has been set, or only for certain editions? I can’t find it anywhere in my professional edition, nor in the [enterprise] NPSP I’m starting to work on, which doesn’t have a role hierarchy and may not need one.

    1. Its more of a concept – this refers to the security that is configured on the list view, dashboard folder, etc. When you modify a list view for example, who can access that list view is a setting at the bottom of the list view config.

  8. You write

    As shown in example 4 above, “Full Access” record-level permission and “Delete” object-level permission are required in order to delete a record.

    This explains why some users may not be able to delete records, even when granted “Read/Write” record access via sharing rules or org-wide defaults.

    In the second sentence, shouldn’t “Read/Write” be “Full Access”. I thought that the point that you were trying to make was that even if a user has full access to a record they might note be able to delete it because they don’t have the ‘delete’ object-level permission.

  9. You write

    As shown in example 4 above, “Full Access” record-level permission and “Delete” object-level permission are required in order to delete a record.

    This explains why some users may not be able to delete records, even when granted “Read/Write” record access via sharing rules or org-wide defaults.

    In the second sentence, shouldn’t “Read/Write” be “Full Access”. I thought that the point that you were trying to make was that even if a user has full access to a record they might note be able to delete it because they don’t have the ‘delete’ object-level permission.

    1. No, the point I’m trying to make is that if the record is shared with read/write access via sharing rules, they may not be able to delete the record even if they do have delete access, because they wouldn’t have full access to the record.

    1. For the majority of settings, Professional and Enterprise should behave identically.

      Professional does not support record types, which does have some impact on security (page layout selection).

      1. I thought the Field Level Security video indicated that Field Level Security was only available for Enterprise, Unlimited, Performance, and Developer Editions (and therefore NOT Professional). Did I misunderstand?

    2. To recap:

      Professional edition and below [edited for clarity]
      -no field level security
      -no custom profiles
      -no record types

      Enterprise and above
      -FLS
      -custom profiles
      -record types

      Thanks for the discussion here folks – I don’t use professional edition often, so this has been a refresher for me as well.

Leave a Reply