Security Matrix

ProfileLogin Hours
Login IP Ranges
API Enabled
Read (Listed as "Read-Only" in config)
Edit (Listed as "Visible" in config)
View All Data
View All (Per Object)
Modify All Data
Modify All (Per Object)
View All Data
Modify All Data
Permission SetAPI EnabledCreate
View All Data
View All (Per Object)
Modify All Data
Modify All (Per Object)
View All Data
Modify All Data
Role(No Impact)(No Impact)(No Impact)Sharing Rules
Role Hierarchy
Folder Sharing Criteria
Group Membership(No Impact)(No Impact)(No Impact)Sharing Rules
Role Hierarchy via Sharing Rule
Folder Sharing Criteria
Org-Wide Defaults(No Impact)(No Impact)(No Impact)Default Access per Object(No Impact)

“Folders” is a non-technical term that is used only on this site, and may not be referenced in Salesforce documentation.  This “Folders” concept refers to many of the containers not addressed in the other security controls (list views, for example).

This matrix should serve as a starting point for tracking down security-related issues, although it is not an all-inclusive list by any means.

41 Responses to “Security Matrix”

  1. March 21, 2017 at 7:17 pm #

    How about include Network Access -> Trusted IP Ranges (can impact Org’s Login) on this Matrix?

    • JohnCoppedge March 22, 2017 at 11:43 am #

      Trusted IPs would bypass activation true- I limit the info on this matrix to just the critical elements (it would be pages long with every feature listed)

  2. trpbt February 24, 2017 at 7:56 am #

    please suggest: How can a System Administrator restrict users from viewing certain fields in list views, searches and reports?
    A. Using field level security
    B Hiding it in profile

    I think Option A is correct.

    • anar020509 March 7, 2017 at 11:01 pm #

      Nope Option B is correct

      • JohnCoppedge March 11, 2017 at 8:56 pm #

        The question answers are not very clear- you would hide the field using field level security, which can would impact the profile

  3. partsgirl2002 January 23, 2017 at 7:23 pm #

    The link you have for “Viewing Which Users Have Access” on this page, as well as on the “Security Model – Free” page is not working.

    The page has an error, it says “DOCUMENTATION_NOT_FOUND”

    Since you mention this page is “a more comprehensive view of record-level security”, I thought you should know it was not working. I am not sure if it has been moved, I was not able to search and find it on my own.

    Thank you!

    • JohnCoppedge January 26, 2017 at 7:07 pm #

      Thanks for the heads up – I’ve been trying to find a replacement for this one and haven’t had any luck. Using the “help for this page” in salesforce also returns this documentation not found, so I think this may be replaced soon.

  4. Chillikaps September 22, 2016 at 4:57 am #

    Hi John,

    I’m confused as to why under Profiles>Records you show View All Data and View All (Per Object). Are there two options when setting a Profile? Also, you refer in a previous comment to “Record Level Security” (you also refer to it in the Security Overview). I’d like to get that cleared. Is record level security what I’d set using OWD?

    • JohnCoppedge September 27, 2016 at 1:12 am #

      Yes there are two options – modify all data is a checkbox on the profile, which grants access to all objects; Modify All can also be granted on a per-object basis in the profile settings as well.

      OWD sets the baseline for record-level security. Sharing rules extend. Profiles can override those record level security permissions (e.g. for administrators) through modify all or view all. Hope that helps!

  5. February 7, 2016 at 10:02 am #


    I got a bit mixed up looking at the matrix. I understood that on Profile I can determine what Object will be available for a certain profile. And that Role will determine what records user may see (or edit). Why is than Records column is also indicated on the profile row?
    View All Data
    View All (Per Object)
    Modify All Data
    Modify All (Per Object)
    I should I understand that?

    Thank you,

    • JohnCoppedge February 7, 2016 at 7:01 pm #

      The view all and modify all would override record level security when granted (that’s why admins can modify all record regardless of where they are in the role hierarchy)

      • February 7, 2016 at 8:45 pm #

        Understood, thank you!

  6. February 7, 2016 at 9:55 am #


    I know this is basic question but I rather ask it though.
    What is in other words “API Enabled” (in the context of this matrix)?

    Thank you,

    • JohnCoppedge February 7, 2016 at 6:55 pm #

      Api enabled determines if the user can login programmatically (eg via the data loader)

  7. lkulik January 27, 2016 at 12:51 pm #

    Small issue: Right hand panel with topics list is missing 🙁

    • JohnCoppedge January 27, 2016 at 11:23 pm #

      Yes- it needs to be on the page to display the whole matrix. You can navigate through the menu at the top of the screen.

  8. sampada.deshpande November 10, 2015 at 7:53 pm #

    Never mind, I answered my own question. I clicked the small “I” link under View All/Modify All, looks like my above statement is accurate.

  9. sampada.deshpande November 10, 2015 at 7:52 pm #

    Hi John,
    I’m unclear about View All and Modify All settings. what does that mean? That the user can see and modify all the records (even those where he/she is not the owner)?

  10. zawar September 23, 2015 at 5:01 pm #

    hi John, why are the “No Effects” crossed out?

  11. Gautam Kasukhela May 25, 2015 at 4:47 pm #

    Hello John,

    Under the Column, ‘FIELDS’ for a Permission Set (in the security matrix), you have mentioned it as Visible,Read Only.
    Should it not be Read and Edit. Because under Permission Set > Object Settings, we can always select an object and edit the field permissions for a particular field to have either Read or Edit or both.


    • JohnCoppedge May 31, 2015 at 5:50 pm #

      Same thing – except under profile it is listed as Visible and Read-Only rather than Read and Edit. Will make a note about this.

  12. Rena Bennett-Dellwo May 1, 2015 at 11:04 pm #

    Thanks for all your help with this, John. It’s a tough subject and I have been struggling with it for about 5 months. I finally feel like I’m getting closer. Woo-hoo! 🙂

  13. JohnCoppedge May 1, 2015 at 10:43 pm #

    Yep that’s right

  14. Abdul Malik Mohammed April 10, 2015 at 4:08 pm #

    Hi John,

    Excellent Matrix. You have def put your heart into it.

    I need a quick clarification. I am struggling to understand the difference between OWD and Sharing Setting. Also what does mean by “Enable External Sharing Model”?

    Thank you.

    • JohnCoppedge April 14, 2015 at 1:48 am #

      OWD sets the base record-level access for all users in the org. Sharing rules add additional record level access for specific sets (roles/groups/etc) of users. If you wanted one set of users to have a different level of access than other, then typically you would set the OWD to the lower of the two, and then using a sharing rule to grant additional access to the second set of users.

      External sharing refers to sharing to defining different OWDs for internal and external (portal, community) users.

      • Abdul Malik Mohammed April 14, 2015 at 2:12 am #

        Thanks for the reply and clarification

      • Rena Bennett-Dellwo April 30, 2015 at 3:21 pm #

        I’m having a lot of trouble wrapping my head around this (and have been for months), so any help would be appreciated.
        An example: A User has CR profile/permission set rights to the Account object and the Account records they own. Can a sharing model (OWD, Role Hierarchy, etc.) provide full (or more than CR) access to Account records not owned by this user?
        Or, can the sharing model only provide the user with up to CR (their profile) permissions?

        • JohnCoppedge May 1, 2015 at 6:50 pm #

          Role hierarchy can provide full access. OWD and sharing rules can only provide read or read/write. Full access provides delete and transfer rights – delete must also be present on the profile (object level permissions), without that they could not delete their own records either. Hope that helps!

          • Rena Bennett-Dellwo May 1, 2015 at 7:46 pm #

            Great! Thanks. And, to add to this (from your answer to my other, similar post): “You are granted the lowest combination of all of the permissions. E.g. in order to edit a record, you need edit at the object level and edit access to the record. So if your profile is read only on the account object, you will never be allowed to edit account records.”

            Therefore, even if Role Hierarchy provided more access on the record level, you couldn’t have more access than what you had on the object through profile/permission sets.

          • Gautam Kasukhela May 25, 2015 at 4:28 pm #

            Hello John,
            Can you kindly help me with the reasoning of your statement above “Role Hierarchy can provide full access.”
            I was under the assumption that a Role Hierarchy can open up record access (in 3 ways viz. No Access, View Only, View n Edit) when the OWD is set to anything more restrictive than Public Read/Write. So how can Role hierarchy provide full access? By full access, i Ma assuming you meant CRED.


          • Gautam Kasukhela May 26, 2015 at 3:26 pm #

            Hello John,
            I think I found the answer to my query on Role hierarchy providing full access. Missed the concept of a user being above the record owner and thus gaining access to records under him/her in role hierarchy.
            Kindly do correct me, if my understanding is flawed.


  15. Sue Maass March 20, 2015 at 11:32 am #

    Since the Who Sees What Series order is Org, Objects, Records, Fields. Could the grid show the same order? Thanks

  16. Cloud Force March 17, 2015 at 3:52 pm #

    Hi John,

    How to enable folder permissions – (view all data and Modify all data) under profile and Permission sets?

    Also, Please provide some more examples when to user Roles over other features like groups?


  17. tim messink February 5, 2015 at 11:24 pm #

    I believe the above matrix implies the user has already logged in gaining access to the system Jason, do you agree John?

    • JohnCoppedge February 6, 2015 at 12:40 am #

      The organization column describes the ability for the user to login to SFDC, make sense?

  18. Jason Shin February 7, 2014 at 1:52 am #

    For OWD on Organization, I thought the Trusted IP Ranges were set on this platform, (as per explained in the User Authentication section:
    Please verify.

    • JohnCoppedge February 10, 2014 at 3:17 am #

      Good question – OWD refers to organization-wide defaults per object (setup –> security controls –> sharing settings). Trusted IP ranges are not reflected on this page.

  19. Kaira Bergstra January 17, 2014 at 9:34 pm #

    *No Effect. Affect as a noun means emotion.

Leave a Reply