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 User Setup & Login Process – Free.  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:

 Create RecordView RecordEdit RecordDelete Record
Object-level permissionCreateReadEditDelete
Record-level permissionN/ARead OnlyRead/WriteFull Access
Scenario:  A user must have the ability to create a lead records.

Required permissions:

“Create” object-level permission on Lead.

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.

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.

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.

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

ResultRead AccessEdit Access
Field EditableCheckedChecked
Field Read-OnlyCheckedUnchecked
Field HiddenUncheckedUnchecked

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 User Interface, 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 Responses to “Security Overview”

  1. markdenford August 25, 2016 at 1:51 am #

    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

    • JohnCoppedge August 25, 2016 at 4:10 am #

      Thanks for the heads up! Haven’t completed the summer 16 updates- that will definitely need to get updated. Makes a lot more sense too!

      • markdenford August 25, 2016 at 10:02 am #

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

      • Thepride21 November 12, 2016 at 1:51 am #

        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?

        • JohnCoppedge November 12, 2016 at 11:50 am #

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

    • JohnCoppedge August 25, 2016 at 11:08 am #

      Update materials on this page- going to do some additional reviews

    • Chillikaps September 9, 2016 at 3:19 am #

      I believe this change only takes effect if you don’t have the “Enhanced Profile User Interface” turned on.

      • markdenford September 9, 2016 at 10:43 am #

        From memory I had enhanced user profiles turned on, but I’m not able to test that now.

  2. MKlobe May 19, 2016 at 11:40 pm #

    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. isullisp October 30, 2015 at 11:50 am #

    sorry, I meant to refer to the section “Record Security”, not “Record Access”

  4. isullisp October 30, 2015 at 11:48 am #

    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!

    • JohnCoppedge November 9, 2015 at 3:35 pm #

      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.

  5. devi September 30, 2015 at 10:24 pm #

    Hi John,

    Do you have the videos for “security model” topic?

    Thanks!

    • JohnCoppedge October 2, 2015 at 3:20 pm #

      I haven’t personally produced anything because I think the Who Sees What Series does an excellent job.

  6. Farzana Hafiz August 19, 2015 at 9:20 am #

    simply excellent

  7. Grant Copenhaver April 7, 2015 at 12:03 am #

    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!

    • Grant Copenhaver April 7, 2015 at 12:20 am #

      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.

      • JohnCoppedge April 7, 2015 at 3:07 am #

        Thanks Grant – good thought and a great example of learning by exploration. FYI – the sharing button goes away when OWD is set to read/write, as it is redundant.

  8. Sonu Sidhu March 26, 2015 at 8:00 pm #

    Hello,

    Which category would Organization Wide sharing setting fall under?

    Thanks
    Sonu

  9. Cloud Force March 11, 2015 at 1:24 pm #

    Hi John,

    The images are failed to load under the topic – “Security overview”.

    • JohnCoppedge March 11, 2015 at 2:59 pm #

      Hrm I am not seeing any issues – can you try another browser and clear your cache?

  10. Kristina Paster February 13, 2015 at 11:59 pm #

    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?

    • JohnCoppedge February 14, 2015 at 12:53 am #

      Click on the field itself in setup, and then click View Field Accessibility – the info is the same, just presented in different places/formats.

      • Kristina Paster February 17, 2015 at 12:14 am #

        Got it! Thank you 🙂

  11. Harleen MANN November 14, 2014 at 5:51 am #

    Got it. So most restrictive access level would be valid. Tx again

  12. Harleen MANN November 12, 2014 at 3:11 am #

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

    • JohnCoppedge November 14, 2014 at 5:49 am #

      Least access:

      1. read at object and field
      2. read at field, but can potentially edit other fields on the object

      Also consider that you would have to weigh in with record-level access as well 🙂

  13. Jeanne Busch October 20, 2014 at 8:53 pm #

    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.

    • JohnCoppedge October 23, 2014 at 12:55 am #

      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.

  14. Ranjana Joshi October 10, 2014 at 8:55 pm #

    When do you use Organization wide defaults?

    • JohnCoppedge October 19, 2014 at 2:10 am #

      To set the record level security for all records within an object for all users in the org.

  15. Alex Messinger September 25, 2014 at 8:03 pm #

    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.

    • JohnCoppedge September 27, 2014 at 10:39 pm #

      No – you need the delete object level permission AND full record level access. Read/write and full access are not the same – that’s the critical part of the story above.

  16. Alex Messinger September 25, 2014 at 8:03 pm #

    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.

  17. Chuck Fernald August 23, 2014 at 6:19 pm #

    I found this SFU video to be very helpful and a good compliment to your content here: https://www.youtube.com/watch?v=17dr2GMvgd8. About 30-40 min is dead air while workshop attendees confer at their tables so it’s not as long as it initially appears. Thanks, John for great site.

  18. Matt Foster May 23, 2014 at 1:49 pm #

    What level of security can you set for Professional vs. Enterprise?

    • JohnCoppedge June 10, 2014 at 9:23 pm #

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

      • Lee Sauer February 7, 2015 at 9:18 pm #

        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?

      • Lee Sauer February 7, 2015 at 9:25 pm #

        In addition, I believe that custom profiles are not available for Contact, Group, and Professional Editions.

        • JohnCoppedge February 8, 2015 at 6:26 pm #

          I’d have to check the docs for the specifics, but yes custom profiles are not supported in professional edition.

    • JohnCoppedge February 8, 2015 at 6:30 pm #

      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.

      • Ksenia Choate February 14, 2015 at 12:42 am #

        Did you mean to say “Professional edition and below”?

  19. Chris Lagarde March 28, 2014 at 3:50 pm #

    Just reviewed this section again, and would like to suggest you change “example” to “column”. To me, it’s the fourth column.

  20. Jim Garrison March 10, 2014 at 6:00 pm #

    John-

    The Department of Redundancy Department called…

    “Full Access” is granted to:
    The record record owner.

    🙂

  21. EAPEN MATTHEW March 4, 2014 at 1:07 pm #

    Excellent summary!

  22. Lipika Brahma February 16, 2014 at 6:10 pm #

    Very aptly summarized.

  23. Josh Rosenberg January 28, 2014 at 10:14 pm #

    3rd bullet has a typo under ‘Organization Security’

  24. Daniel Sokolowski November 1, 2013 at 3:36 pm #

    FYI: the word “IN” is missing in the sentence: “Note: Page layouts also influence which fields a user can update within the User Interface, which is discussed the future.”

Leave a Reply