Security Model – Free

ObjectiveResourcesKey Facts
Describe the core principles of the security model.Who Sees What: Data Visibility How to Series
[Must / ~50m /]
[Who Sees What: Organization Access repeated from User Setup & Login Process – Free]

(This series is also available via Vidyard but does not appear to contain the entire series.)
The "Who Sees What" series is a great introduction to Salesforce security. If you have not watched the series before, I recommend watching these videos in order. Objectives and resources to follow will expand on these concepts.
Describe the capabilities of the User Sharing feature.Understanding User Sharing
[Could / Long /]
User Sharing allows an administrator to set the user object org-wide default (OWD) to private. This feature is enabled by default for orgs created after the Winter 14 Release. To enable this feature in an existing org, contact support.
Describe how access to data and functionality is structured within Salesforce.Security Overview
[Must / Medium /]
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.

Folder Security: Determines access to a variety of information including reports, dashboards, email templates, and more.
Explain who can delete records in Salesforce.

Security Overview

To delete a record, the user must have the "Delete" object permission (profile or permission set) and "Full Access" to the record. "Full Access" is typically granted to the record owner, users higher in the role hierarchy than the record owner, and system administrators.
Describe profiles and their influence on security.Profiles
[Must / Short /]

User Permissions
[Must / Medium /]

Who Sees What: Object Access

Each user is assigned one profile, which is instrumental in determining a user’s functional access (apps, tabs, object-level permissions), how information is displayed to the user (page layouts, record types, field-level security), and a wide range of other permissions.
List and describe the standard profiles.Standard Profiles
[Should / Medium /]

Who Sees What: Object Access

Ensure that you understand the Salesforce license standard profiles:
Contract Manager
Marketing User
Read Only
Solution Manager
Standard User
System Administrator
Explain when to create a custom profile.


As customization of standard profiles is limited, create custom profiles prior to assigning users to profiles.
Describe permission sets, and common use cases where they are appropriate.Permission Sets
[Must / Short /]

Overview of User Permissions
[Must / Short /]

Winter '12: Efficient, Manageable Security Policies with Permission Sets
[Should / Medium /]

The Permissioner
[Could / Package /]

Who Sees What: Permission Sets
(Repeated from Who Sees What Series above)

User Permissions

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).
Describe how Organization-Wide Defaults (OWDs) influence security.Sharing Default Access Settings
[Must / Medium /]

Default Organization-Wide Sharing Settings
[Should / Short /]

Who Sees What: Org-Wide Defaults

Organization-wide default settings determine the default record-level permissions granted to all users for all records within each object. For instance, setting the Account object to "Public Read/Write" will ensure that all users have "Read/Write" record-level permissions to all account records.

The most commonly used settings are:
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 (Cases, Leads): Full record access granted
Controlled by Parents (Contacts, Activities): Parent record controls access
Describe roles and their influence on security.Roles
[Must / Short /]

Who Sees What: Access via Roles

A user's role sets the foundation for what records and folders they can access. Users are granted full access to records owned by users in subordinate roles on objects where "Grant Access Using Hierarchies" is enabled.
Describe public groups and their influence on security.Groups
[Must / Short /]
Public groups are used to streamline the process of sharing access to records and folders. A group is comprised of users, roles, and other groups.
Describe manager groups and their influence on security.Sharing Records with Manager Groups
[Should / Medium /]
Manager Groups are used to share access to records based on the user's manager (specified via the manager field on user record).

Manager Groups is disabled by default, but can be easily enabled by the system administrator.
Describe sharing rules, and when their usage is appropriate.

Who Sees What: Record Access via Sharing Rules

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 can extend either Read Only or Read/Write access.
Describe a queue's influence on security.

User Setup & Login Process – Free

Ensure that you understand the fundamentals of queues - see User Setup & Login Process – Free for more.

When a user is a member of a queue and a record is owned by a queue, then the user will inherit "Full Access" to that record.
Explain how manual sharing can be used to extend record access.Manual Record Sharing & Auditing
[Must / Short /]
Users can manually share access to records that they own with other users, roles, and groups.
Describe delegated administration.Delegated Administration
[Must / Short /]
Whereas profiles and permission sets grant the ability to administer all users and objects, delegated administration allows administration of only specified users (based on roles/profiles) and specified custom objects.
Describe the capabilities of Custom Permissions.Custom Permissions Overview
[Could / Short /]
Custom permissions can be used to define permissions within a custom application or process.

For example, your organization has implemented a custom application in Salesforce to track leave requests. One of the buttons in the application invokes a custom process (apex/VisualForce code) to mass approve leave requests.

Previously, if a developer wanted to define a permission to mass approve leave requests, this was often configured through the use of a custom field on the user object (e.g. checkbox "Can Mass Approve Leave Requests") or via the use of a hierarchy-based custom setting. Both of these approaches have limitations.

With custom permissions, a developer can define a permission to represent the user's ability to mass approve leave requests. This custom permission can then be assigned through the use of a profile or permission set, like any standard Salesforce permission.

Creating and defining custom permissions would be performed by a developer. However, administrators should be aware of custom permissions and the potential security implications when used.
Describe the capabilities of Single Sign-On (SSO).About Single Sign-On
[Should / Medium /]

Single Sign-On Implementation

[Could / Long /]
Single Sign-On provides the capability for a user to login to one system and have access to one more additional systems facilitated systematically as a result. For example, a user may authenticate to their network through Active Directory (Microsoft Windows) and thereby be granted access to without providing a username and password.
Describe the capabilities of the Salesforce App Launcher.Setting up the App Launcher
[Could / 6m / CTOBuddy]
The Salesforce App Launcher is a single sign-on portal, allowing users to launch both Salesforce and external applications (external apps via single sign-on).
Describe the resources to monitor Salesforce system performance and
[Must / Short /]
Use to monitor system and security status, as well find best practices from Salesforce.
Given a scenario, determine the appropriate security configuration.Security: Scenario 1
[Must / ~10m /]

Security: Scenario 2
[Must / ~10m /]

Security: Scenario 3
[Must / ~10m /]

Security: Scenario 4
[Must / ~15-30m /]

All Objectives Met

Security Matrix
[Should / Short /]

A Guide to Sharing Architecture
[Could / Long /]

Record-Level Access: Under the Hood
[Could / Long /]

Workshop: What's Possible with Salesforce Data Access and Security
[Could / 2h9m /]

Nailing the “Gotcha” Questions
[Must / Medium /]

Security: Quiz
[Must / Short Quiz /]

Security: Advanced Quiz
[Must / Short Quiz /]

Security: Feedback
[Should / Feedback /]
Finished this section?  Next section: Data Model - Free

141 Responses to “Security Model – Free”

  1. bigshane December 10, 2017 at 1:23 am #

    heres the updated video series.

  2. kj85 September 18, 2017 at 3:47 pm #

    Hi John ,

    I have a quick question on the article ” A Guide to Sharing Architecture ” under All objectives Met section . In that article –> under Record Ownership and queue section on page 2 , it says that User higher in hierarchy inherit the same access as their subordinates for standard objects. If subordinate has Read only access so will the manager. Is that true ? I thought Manager has full access to record ( minus the delete ) owned by subordinates. Please clarify .


    • JohnCoppedge September 22, 2017 at 1:36 pm #

      They inherit record security through the role hierarchy. The owner of the record will always have full access to the record, which will get inherited upwards via role hierarchy.

      However to take an action you need access both at the record, and object level. So an owner of an account can’t edit the account without also having the object permission to edit.

      Example scenario:

      User A is assigned Account B. User A has full access to Account B. User has profile permissions to read account object (no others). User A can only view the account they are assigned.

      User X is assigned above User A in role hierarchy. User X inherits full access to Account B (despite User A cannot edit the record b/c of object permissions).

      • kj85 September 28, 2017 at 6:23 pm #

        I tested the below scenarios to clear my confusion:

        1. User A has CR permission on Account object and is owner of Account B. User X has CR permission so this means User X will also have READ permission on that Account B but can’t edit the record because of profile . User A also cannot edit the Account B
        2. User A has CR permission on Account object and is owner of Account B. User X has CRED permission so this means User X can edit the Account B but User A cannot

  3. MKarp02 September 16, 2017 at 9:35 pm #

    Hi John,

    The Who Sees What series now appears to be available for Lightning Experience via the Salesforce YouTube channel. Any thoughts on whether it’s better to study in Classic v. Lightning mode for the exam?

    • JohnCoppedge December 22, 2017 at 9:20 pm #

      The content should be largely the same for both – I suspect the exam will still lean towards classic though

  4. mattl August 28, 2017 at 7:46 pm #

    Hi John,

    Silly question but I cannot find customize> opportunities under setup (even using quick find). Does one need to enable a feature or contact salesforce in order to set field level security?

    • CarlosSiqueira August 28, 2017 at 7:57 pm #

      You can try:

      Setup –> Field Accessibility –> Opportunity–> View By Fields–> Chose the field that you want to manage.
      Here you can see manage the access by profile and record type.

      If you want other kind of setup, go to Setup and type the name of the standard object like Opportunities, Accounts, etc.

      • mattl August 28, 2017 at 8:08 pm #

        Carlos you champion!

        Thanks pal I am able to do it 100% now.


    • mattl August 28, 2017 at 8:01 pm #

      Nevermind I have found it. Whilst you here :).. My opportunity name has no data for me to set any security so I’m going to have to go and create some test opportunities right?

      Otherwise thanks for the guide and the salesforce “who sees what series” is fantastic thanks for that link.


  5. Conniehuang May 16, 2017 at 5:38 pm #

    Hi John, quick question on the who sees what.

    The OWD is set to private. Phil is the owner of ABC account, is a US sales reps reporting to US sales director. The users in the US sales rep role can edit ALL opportunity associated with the accounts they own. Tim, an EMEA sales rep, owns an opportunity associated with the ABC account. Which one are correct?

    – Phil can view and edit Tim’s ABC labs opportunity (yes that is correct)
    – Time can view but cannot edit Phil’s account (that is correct but why ?)
    – Tim cannot view or edit Phil’s account (I thought this one is correct but no)

    Thanks a lot!

    • JohnCoppedge June 1, 2017 at 9:12 pm #

      The reason that Tim can view the account is because he owns an opportunity related to that account – this in turn grants him read access to the account (that’s why #2). WIthout some other reason (e.g. role hierarchy, sharing rule, etc.) Tim is not going to have any additional access (why not #3)

  6. April 19, 2017 at 8:32 pm #

    Hi John,

    I have a a scenario where

    There are 8 organisations using my instance. I created a custom object and added all the organisations as records.
    there are many facilities(Accounts) where each facility can be a part of many organisations and each organisations can have many facilities. I created a junction object to achieve this requirement. So far so good.

    Now I want to set the access to each organisation user.
    When a user from organisation A will login to salesforce should be able to view and edit the records that are related to his organisation. Also he should be able to view but not edit records that are related to other organisations.

    How can I achieve this. I tried making OWD to public read only and custom object to read/edit under profile. Any changes are giving the same access to all records. Please suggest

    Thank you,

    • JohnCoppedge April 19, 2017 at 9:50 pm #

      Cool question. So that’s a bit tricky.

      The inherent problem with this scenario is that sharing is based on a single object (account), where-as your goal is to share based many records related to the account. So ultimately you need to either:

      a) summarize the related records on the account, then share the account based on that summarized (field) data OR
      b) use a programmatic (possibly process builder or flow) mechanism to create share records that mirror the custom object data (read up on the share object, this is a technical solution) OR
      c) re-purpose an existing feature such as account teams, where you create an account team member (instead of using a custom object) OR
      d) simplest solution: create a multi-select picklist for the organization on each object you implement sharing, then create sharing rules based on the picklist values (assuming you can use multi-selects in a criteria-based sharing rule, which you might not be able to do… if not, you could use 8 checkbox fields) OR
      e) implement territory management (has a bit of overhead and only works for the account and opportunity objects)

      That’s a really open ended but interesting problem (there are probably other solutions as well). Drop a line and let us know what path you choose.



      • April 20, 2017 at 4:01 pm #

        Hi John, Thank you for a quick reply.

        I went through everything thoroughly and thought that

        re-purpose an existing feature such as account teams, where you create an account team member (instead of using a custom object) will solve my issue.

        So now my organisations are the accounts and I add team members deciding the access.
        Now I have a new issue. I will still have facilities that are related to these accounts with many to many relationship. So I created a junction object between accounts and facilities. Now I want to give access to the junction object records that are related in this account can be modified by the team member but he should not have the privilege to modify other organisation records. As this is a custom object. how should I proceed further.


        • JohnCoppedge April 20, 2017 at 4:49 pm #

          The junction object (if m/d) inherits permissions from the parent object (account), so if the user doesn’t have edit access to the parent object, then they won’t have access to the modify the junction.

          In the settings for the junction object, you can further tweak the permissions of this relationship.

          Ultimately you should aim to set the permissions on either the account (via account team) or facility then allow the junction object to inherit those permissions.

          • April 20, 2017 at 5:41 pm #

            My Problem is If I am making the user profile as any standard profile he is not able to see any of the custom object records. So I have create a custom profile and give view all access on the custom object permissions. This is deciding the record access of the object for the user. How should I limit this

          • April 20, 2017 at 5:52 pm #

            I achieved it thank you for the support

          • April 20, 2017 at 6:09 pm #

            Hi John,

            On the account team I can give access to account opportunity,contact and account.If my Custom object is a junction between Account and Opportunity or Contact it is controlled by parent hence I give OWD as public read and set the account team access for the parents it is achieved. What if my junction is between Acoount and other custom object. How will I control this access.

            Thank you,

  7. arulnarayan April 11, 2017 at 1:06 am #

    Link “Single Sign-On Implementation Guide” goes to a page that does not exist.

  8. arulnarayan April 10, 2017 at 10:46 pm #

    Link “Understanding User Sharing” is going to a page that does not exist.

  9. March 21, 2017 at 2:21 pm #

    Hi ,
    I need to confirm the answer to this question :
    Universal containers set the organization-wide defaults for cases to private. When a case is escalated, case ownership changes to Tier 2 support agent.

    How can a system administrator give the sales operation team read/write access to all escalated cases?

    a. Create a case escalation rule.

    b. Create a case assignment rule.

    c. Create a criteria-based sharing rule.

    d. Create an ownership-based sharing rule.

    I believe the answer should be “d” .Since the criteria of the case being “escalated” is already met and the ownership of the record has changed.As a next and final step I can just create an ownership-based sharing rule to share the record with the sales team with the right level of I thinking in the right direction?any thoughts anyone?


    • JohnCoppedge March 21, 2017 at 2:33 pm #

      Where did this question come from? The answer is most likely C- as the criteria would be “isescalated”. This question was recently asked on another page (please don’t double post if that was you)- thanks!

      • March 21, 2017 at 6:13 pm #

        One of the sample questions I found online..and no I havn’t posted this question before..


      • June 20, 2017 at 7:52 pm #

        I’d love to know the answer to this. I have found mixed answers online. Is it Criteria-Based or Owner-based sharing? I lean to criteria-based bec it doesn’t tell us whether the Tier 2 support agent has the ability to transfer their cases in which case it wouldn’t be safe to assume that they didn’t transfer a case to someone else. To be safe the isescalated = TRUE would be the criteria to share on – can you please confirm?

        • JohnCoppedge June 21, 2017 at 1:04 am #

          Yes I would answer this as criteria-based sharing (although to be 100% sure I would actually configure and test it out in my environment)

  10. kmkaast March 8, 2017 at 7:36 pm #

    Viewing Which Users Have Access link not working , Documention not found , under Explain how manual sharing can be used to extend record access. step

  11. sidhant.padhiary March 8, 2017 at 3:32 pm #

    Hi John/All,

    Can someone help me understand why Role field is shown as a mandatory field while creating user and in developer edition I am able to create users without assigning a Role to them. So, is Role mandatory while creating user? If not, then what is the purpose of showing Role field as Mandatory. Any urgent reply would be really appreciated.

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

      Role is shown as mandatory but you can select “none specified”, which leaves the role blank. In short it is listed as mandatory but in actuality is not.

  12. Sal March 5, 2017 at 9:15 pm #

    Can someone tell me the difference between a manager group and an accounts team ?

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

      They are not related – manager group looks at the manager field on the user record to facilitate sharing. Account teams are used to build sharing on an account record based on who is involved in the management of the account.

  13. Sal March 3, 2017 at 11:24 pm #

    A custom field is made Read only from the Field level security and Required from Page layout. The Field will be

    A. Read Only for the User
    B. Required for the User
    C. Throws an error and don’t allow to make Read only field Mandatory from page layout
    D. User is given a choice in a pop up window

    • CarlosSiqueira March 3, 2017 at 11:38 pm #

      Option A.

      If you are an Admin, you might be able to edit the field.

  14. cascadeherriott February 28, 2017 at 12:40 am #

    ‘Viewing which users have access’ link dead ends.

  15. sidhant.padhiary February 26, 2017 at 12:39 pm #

    Hi John,

    Thanks for making a great site for all newbies.

    I wanted to understand why Role field is shown as a mandatory field while creating user and I am able to create users without assigning a Role to them. Is Role mandatory while creating user? If not, then what is the purpose of showing Role field as Mandatory.

    • JohnCoppedge March 13, 2017 at 3:53 pm #

      It is technically speaking not mandatory… its just a quirk that it shows as required (it almost always *should* be populated)

  16. anneverner February 15, 2017 at 8:50 pm #

    In the You Tube video “Who See What Overview”, it shows Field Accessibility as having the option to be viewed by either Profiles or Record Types. However, in the Developer edition I am using, you can only view Field Accessibility by type of record for which you would like to grant access.

    Can you confirm if this is different in Developer vs other editions?

    • JohnCoppedge February 15, 2017 at 11:42 pm #

      Field level security is independent of record type (and is determined by profile/record type)… can you point me to the video/spot you are talking about (there might be a spot in setup where you can view FLS by record type, its just not something I’ve used recently)?

      • anneverner February 16, 2017 at 2:36 am #

        I think I found my answer. It is at about the 3:52 mark in the 1st video. I just didn’t go deep enough in my Developer edition; the choice to view by Profiles or Record Types comes AFTER you choose which object you want to edit. The videos move along quickly so will be sure to have my coffee first next time!

  17. Champakali January 19, 2017 at 4:09 pm #

    Hi John, great Site!
    FYI: Dead link for Topic “Viewing Which Users Have Access”: Documentation not found.

    • JohnCoppedge January 20, 2017 at 10:02 pm #

      Yes it sure is … also dead from with the Salesforce app. I’ll check back in a week or so and see if there’s a replacement

  18. adjoam December 18, 2016 at 4:01 pm #

    hi john
    is it possible for a user to own a record but not be able to see it?

    • JohnCoppedge January 20, 2017 at 10:00 pm #

      Yes – if they already own the record and then access is revoked (e.g. read access removed on opportunity on the user’s profile) then they would still own it but could not be assigned new records

  19. trpbt December 17, 2016 at 6:53 am #

    hi john,l

    Which of the following is the best way to make the Field Mandatory for everyone?

    A. Page Layout
    B. Validation Rule
    C. Roles & Profiles
    D. Field Level Security

    • adjoam December 18, 2016 at 4:05 pm #

      i think it’s B ..

      A. Page Layout – would only make it mandatory on specific page layouts
      B. Validation Rule
      C. Roles & Profiles – not applicable
      D. Field Level Security – not applicable as this only determines whether fields are visible/read only/hidden

    • anumedha May 13, 2017 at 7:56 pm #

      Hi John

      Can you explain which one is the best way to make field mandatory and why
      ? There is lots of confusion regarding this question .


      • JohnCoppedge May 16, 2017 at 2:36 pm #

        The best way to make a field mandatory is in the FIELD SETTINGS, lol… there are a lot of similar questions out there and the correct answer isn’t listed 🙂 Assuming that you really want the field to be required for everyone, all the time.

        Second to that, a validation rule is the best way to ENFORCE a field requirement.

        Page layouts can only enforce the field requirement if the user has visibility to the field, which is not always the case.

        • anumedha May 16, 2017 at 5:41 pm #

          Thanku so much John for ur reply.


  20. aventadorkinnu December 13, 2016 at 9:31 pm #

    Quick question regarding IP address. A company has an IP range set up and a user’s profile has a specific IP address. If the user moves out of that IP range but is still under the company’s IP address range, will the user be denied access, granted access or will be required to enter a security code ?

    • JohnCoppedge December 16, 2016 at 11:49 pm #

      There are two types of IP ranges:

      trusted and login ranges

      if they login outside of trusted, then they need to activate
      if they login outside of login ip ranges, then login will be denied

      login ip ranges (restrictions) will override trusted ranges

  21. November 19, 2016 at 3:57 pm #

    This link appears to be empty. Winter ’12: Efficient, Manageable Security Policies with Permission Sets

  22. CarlosSiqueira May 27, 2016 at 5:46 pm #

    I just can’t. Since this is a training environment, I removed all the permission sets associated with Opportunity. Now, when I log as Matt and try to share the Opportunity, I can only share with user Matt. I created a permission set for the role EMEA Sales Rep (Karen’s role) and then I can share the Opp with Karen, but all EMEA Sales rep get the same access. I will try to remove some other stuff and see if works. I tried similar scenario on a Production environment and it worked fine. Really strange because Matt and Karen have the same profile and Matt owns both the Account and the Opportunity, still unable to share either with Karen.

  23. CarlosSiqueira May 25, 2016 at 1:37 pm #

    I have 2 users with profile as Sales User. OWD for Opportunity is private. Matt has a role as US Sales Rep and Karen has a role as EMEA Sales Rep. Under Security Control/Sharing Settings/Opportunity sharing rules, I see a Global Sales Rep Group which contains ALL Sales reps (US, EMEA, APAC) sharing ALL Opportunities with ALL Sales Rep as read only. When I login as any user with a profile Sales User, I can see any Opportunities (US, EMEA, APAC) regardless of owner/role.
    When I login as Matt, I want to share all his Opportunities with Karen or at least one Opportunity.
    I tried a permission set with read/edit access to Opportunities and added Karen, when I log as Karen, I can read but can’t edit Matt’s Opportunities. I logged again as Matt, chose one Opportunity and clicked on Sharing. I can pick Public Groups, Roles, Roles & Subordinates, Users. When I try to chose Users hoping to be able to pick Karen, it shows me only 5 users: One VP of Marketing (role) Excutive User (profile), one APAC Sales Rep (role) Sales User (profile), 2 Marketers (Role) General Marketing User (profile) and one Marketing Director (Role) General Marketing User (profile). All these 5 users were grated read only access thru existing Opportunity Sharing rules. If I chose Roles and pick EMEA Sales Rep with read/edit acces, Karen gets edit access to this Opportunity but ALL other EMEA Sales Reps get the same. How can I give access ONLY to Karen to edit this Opportunity that belongs to Matt? I thought manual sharing was exactly that. Sorry for the long question.

    • JohnCoppedge May 27, 2016 at 3:18 pm #

      You should be able to share the record directly with Karen – does Karen already have access to the record? If not have you tried specifically searching for her name?

  24. bilabongster April 11, 2016 at 3:23 pm #

    Hey John,

    I have troubles understanding something.

    While in the Salesforce video that explains role hierarchy, it shows view/edit access can be controlled through roles as well. But when looking at dev org, there is no option to choose whether we can control view / edit access through roles as well.

    • JohnCoppedge April 13, 2016 at 9:02 pm #

      Access is granted via the role hierarchy (those in higher roles auto inherit access to records owned by those below) and through sharing rules to grant additional access. You are correct that there is a limited impact to security by configuring the role directly.

  25. Kat Radzetskaya March 30, 2016 at 3:54 pm #

    If I update the password in Salesforce,will SSO reflect it and the other way around it. If I update the password in SSO will the password be update in SFDC?

    • Kat Radzetskaya April 1, 2016 at 1:43 pm #

      John, any thoughts?

      • JohnCoppedge April 10, 2016 at 11:01 pm #

        I don’t think you have a password at all with sso enabled. Your source system(eg active directory) performs the authentication. The password is not stored in salesforce in that scenario. Not an expert here, but that’s what I’ve seen working with clients that have it enabled (you will get an error in salesforce if you try to reset the password of a user that has an sso enabled profile).

  26. February 4, 2016 at 8:26 pm #

    Hi john,
    Finally stated working with my first ever free app i got from here “The Permissioner” and its awesome.
    Thank you again.

  27. February 4, 2016 at 6:22 pm #

    Hi John,

    I am not clear about the difference between:
    Role Hierarchy and Sharing Records with Manager Groups

    If an object has Private setting on OWD, the role hierarchy will allow higher roles in the hierarchy of the record owner to access it. Why would i use “Sharing Records with Manager Groups” than?

    Thank you,

    • JohnCoppedge February 4, 2016 at 7:28 pm #

      Manager groups depend on the Manager lookup field on the user.


      Bob (reports to) –> Jim

      Jim (for whatever reason) is not above Bob in the role hierarchy. The Manager group allows you to declare sharing based on the manager field, rather than the role hierarchy (e.g. direct reports only… versus all those lower in the role hierarchy).

  28. January 30, 2016 at 4:05 pm #

    Hi John,

    What are External users? what licence to they have to my org. instance?
    What is partner (user)?

    User sharing for external users
    Users with the “Manage External Users” permission have access to external user records for Partner
    Relationship Management, Customer Service, and Customer Self-Service portal users, regardless of
    sharing rules or organization-wide default settings for User records. The “Manage External Users”
    permission does not grant access to guest or Chatter External users.



    • JohnCoppedge January 31, 2016 at 5:28 pm #

      External users would be customer/partner/community licenses- users in these categories are typically enabled from an existing account/contact record (the resulting user record is linked back to the contact that it was created from).

      If you are curious about this I would suggest enabling communities in your org – create a test account/contact and then grant access. DE orgs have community licenses to test with.

  29. January 25, 2016 at 12:23 pm #

    Hi john,
    It might be a silly question at this stage , but want t know that record access level , sharing rules can only be defined by ADMIN in ur org, ?

    Record owner can also define there sharing rules , to whom they want to share with.
    and further in sharing rules and manual sharing ,,,,and hierechy,

    another question is …when i have OWD more restricted then public Read/Write…

    Hierarchy :
    there is a hierarchy and , if i m a subordinate of manager, and as the rule define at Role hierechy my manager can access my how much manager access allowed for a record at that point( i means is he able to vie,edit,delete,share to others in org.?)

    Sharing Rule:
    same for sharing rule (how much access to the person have with my record access), can he view,edit,delete,or further can share my record to others?
    and same question for manual sharing of my owned record. if i share manually to some user who w/o considering hierarchy…

    Manual sharing:
    how much access do he have with my record which one shared manually with him?
    can he view ,edit, delete, or further share to other user in org.?

    at this point , i m really craving for answer related to effect of security model(profile,Sharing settings and again it relate to one of my question on reports and dashboard).

    you answers Really helping me gain confidence with my Salesforce learning.
    Thank you for putting such an effort to direct learners to the right direction.
    Thank you .Thank you .

    • JohnCoppedge January 25, 2016 at 7:19 pm #

      Sharing rule = defined by admin
      Record level sharing = defined by a user that has full access to the record

      Role hierarchy grants full access for records owned by users below in the role hierarchy (where grant access via hierarchies is enabled, which is the case for standard objects)

      Sharing rule only grants up to read/write (not full access, which grants delete)

      Manual sharing also grants up to read/write (read or read/write)



      • January 25, 2016 at 7:33 pm #

        Thank you john,
        this will help .

  30. November 17, 2015 at 4:44 pm #

    Hi John,
    The following video has been removed, a shame, I saved it to watch it later now that I have completed your guide but it is gone 🙁
    “I love Permission Sets: A Deep Dive Into Profiles 2.0”

  31. November 2, 2015 at 11:09 pm #

    in the Who Sees What: Data Visibility How To Series, the first video “Who sees what: Overview” won’t load. I get an error “Error Code: 200
    : NetStream.Play.StreamNotFound”

    • Celso_Garcia November 3, 2015 at 6:37 pm #

      Works for me. I have a pc using chrome

  32. October 30, 2015 at 1:21 pm #

    Hi John,

    I have a question regarding email notifications I receive as a system admin when OWD settings are changed in SF. How can this be switched off?
    Is this setting only valid when changing OWD or also other config?

    Secondly, the abbreviation SFDC is mentioned quite a lot, what does it stand for?



    • Rena Bennett-Dellwo October 30, 2015 at 2:59 pm #


      SFDC stands for Salesforce Dot (.) Com. Sometimes people just say SF instead.

      Hope this helps. (I don’t have the answer to your other question at the moment. Hopefully someone else does.)


      • November 4, 2015 at 11:02 am #

        Thanks Rena!

  33. Bilal Nawaz October 20, 2015 at 5:27 am #

    Hey John can you please help me to understand this question.

    Accounts teams are used for the following reasons: (Select all that apply)

    a. Share roles with the sales team

    b. Are used for collaborative account management

    c. Are used for sharing and reporting purposes

    d. Are used for splitting of account credit if needed

    what his mean by “Accounts teams”
    its answer is a,b,c but I’m missing something here.

  34. Sps October 19, 2015 at 10:37 am #

    Hello John,

    Thank you for this excellent Website.

    Would appreciate if you could explain or provide a link explaining the difference between team and group in Salesforce. I understand where groups are to be used but no clear understanding on how and when to use teams in sharing.

    Thank You

    • Munira Majmundar October 20, 2015 at 1:31 pm #

      That is a good question. I think Group is mainly used in Chatter and comprises of folks who share common interest or would like to keep themselves abreast on a particular topic; and Team mainly comprises of a group of people, across various teams/departments, that work on specific project. But, it would be great to get more info. on these for clarification.

    • Munira Majmundar October 20, 2015 at 1:36 pm #

      Hello Sps:

      Here is a link that helps clarify the concepts

    • JohnCoppedge October 22, 2015 at 3:11 am #

      Teams are defined for select objects (e.g. accounts, opportunities) and are used to designate which users are involved on the record (e.g. an account team indicates who is involved in managing that accounts) – teams also provide access by sharing the record to the user (so that if you are a member of the account team you can view the record).

      Groups are multi-purpose and are generally leveraged for purposes (e.g. within a sharing rule).

  35. Munira Majmundar September 29, 2015 at 12:06 am #


    I think the answer is A.
    B. can only read , edit their own opportunities , but can view every one else
    VIEW EVERYONE ELSE? Does not make sense.

    Answer A should be correct because it says
    Can read,Edit and view their own and every one else opportunities


    View ALL permission is on Opportunity Object. So, the User will be able to View Opportunities they own AND ALL OTHER RECORDS ON THE OPPORTUNITY OBJECT that others own.

    Pl. correct me if I am wrong.

    • JohnCoppedge September 30, 2015 at 6:49 pm #

      Correct- but if OWD is set to private, then they would not have read/write to all other opportunity records (view all providing only read access)… its not a very clearly worded question though.

      • Munira Majmundar September 30, 2015 at 7:10 pm #

        If so, then, you may want to change your answer to A

        JohnCoppedge September 3, 2015 at 1:32 pm #
        Oh I didn’t see ‘view all’ my mistake – the answer would be b then

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

          I still think the answer would be B. OWD private means that they would only be able to edit and read their own opportunities, then view all would open up view access to all opportunities.

  36. Dharani Animireddy September 1, 2015 at 12:14 pm #

    Not sure it notified as a duplicate, so i just to be on the safer side i am posting only the question ..

    1) when the user profile on the opportunity was set to Edit and read , and view all .OWD is set to private ,The user can

    a)Can read,Edit and view their own and every one else opportunities
    b)can only read , edit their own opportunities , but can view every one else
    c)can only Read, view , edit their own opportunities and they can’t view other opportunities

    My answer is ‘b’ but the answers seems to be ‘a’ .

    I am confused now , can you please help me here???

    • Dharani Animireddy September 2, 2015 at 10:34 am #

      hi can some one help me on the questions please?

      • JohnCoppedge September 2, 2015 at 12:19 pm #

        It depends on where the user is in the role hierarchy. The closest answer is probably c.

        If the OWD is private, that means that the user won’t be able to view or edit opportunity in the same role as they are assigned or any roles above that role. They will be able to view and edit (granted access via the role hierarchy) records owned by users in roles below theirs.

        • Dharani Animireddy September 2, 2015 at 4:26 pm #

          hi John,
          Yes i agree with you depends on Role hierarchy, but if the role hierarchy was not enabled . And the OWD is private.
          But the User profile has ‘View all’ option , that means they can view all other opportunities .

          am i missing some thing here ?

          • JohnCoppedge September 3, 2015 at 1:32 pm #

            Oh I didn’t see ‘view all’ my mistake – the answer would be b then

  37. Thepride21 August 21, 2015 at 1:56 am #

    I am unable to see the videos, they seem to be private. Is there any other source which can help me view these?

  38. Celso_Garcia August 20, 2015 at 2:32 pm #

    This is unfortunate. Yesterday all but one video was view-able. Today only 3 are available. I was only on like the 3rd one in the series and the were great. Why do they keep making them private then public?

  39. Ezekiel Apte July 6, 2015 at 6:10 am #

    This resources provides a visual perspective on Salesforce Security:

  40. bsnavle July 2, 2015 at 7:16 pm #

    Wow… Just loved it. Thanks for letting me know John.

  41. Basava Salini Atluri July 2, 2015 at 1:55 am #

    HI John,

    Who Sees What: Data Visibility How To’s — these videos are made private in you tube. can not access all of them. only 3 videos are made available.

  42. bsnavle July 2, 2015 at 12:42 am #

    Thanks Patrick.
    Only 3 are available.

  43. patrick_j July 2, 2015 at 12:03 am #

    All but three of the videos in the “Who Sees What: Data Visibility How To’s” youtube playlist are now private.

  44. bsnavle July 1, 2015 at 9:23 pm #

    Hello John – I am not able to see all the videos in ” Who Sees What”. It says the videos are Private.
    Do I need any specific user credentials to view those videos ? Please help.

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

    I thought I’d posted this yesterday, but now I can’t seem to find it. I apologize in advance if, in fact, it is a duplicate post.
    For some reason, I’m having problems with this concept, and I’m taking my cert exam next week so I’m more than a little nervous :-).
    If someone has limited or no access at the profile level to an object and – therefore – to records they own, can the OWDs/Role Hierarchy/Sharing Rules/Etc. give them more access to objects and records that they don’t own?
    My instinct would be to say that if you can’t see/edit/etc. your own records at the profile level you can’t see/edit/etc. someone else’s records.

    • Rena Bennett-Dellwo May 1, 2015 at 3:00 pm #

      I don’t think I clicked on “Notify me…”

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

        Correct – 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.

  46. Kevin Brown March 11, 2015 at 5:45 pm #

    Needs editing:

    Each user is assigned a one profile

    …should read

    Each user is assigned a one profile

    Also, a space needs to be between “user(page” in the same paragraph.

  47. Velma McConnell February 20, 2015 at 6:39 pm #

    I’m finding that the user interface screens in the video do not match what I’m currently seeing in the developer or my Enterprise edition. It’s making it a bit more difficult to follow along and find these fields. For instance, there are drop down arrows in the profile settings, but links instead.

    Any idea when SFDC will be updating these fields?

    • JohnCoppedge February 20, 2015 at 6:49 pm #

      You should be able to turn off the new UI:

      Instructions within this guide make the assumption that the Improved Setup User Interface is disabled.

      I suggest you double-check your org settings by navigating to Setup –> Customize –> User Interface; ensure “Enable Improved Setup User Interface” is not checked.

      If you enable this feature, step-by-step instructions within scenarios and exercises will not line up correctly (as the setup navigation menus will be different).

  48. Jasmin Akerele January 16, 2015 at 10:56 pm #

    Hi John,
    In the section “Describe the capabilities of the Salesforce App Launcher”, the link is damaged:
    [sc:youtubelink id=1_cTGhxPJHQ text=”Setting up the App Launcher”]

    BTW, thanks for creating this site…I’m working my way through…

  49. Jeanne Busch October 20, 2014 at 8:59 pm #

    The repeated links for object access still needs to be updated to:

  50. Lisa Seyler October 6, 2014 at 9:24 pm #

    I found a typo – I think you meant to say “comprised” -> “A group is compromised of users, roles, and other groups.”

  51. Kim Snyder September 6, 2014 at 7:12 pm #

    It looks like a number of these have changed. Here’s the new list of these revised videos –

  52. Kim Snyder September 6, 2014 at 6:54 pm #


    The Who Sees What Organization-wide Defaults video has been updated – here’s the new link –

    Thanks so much for this training series!

  53. Algy George August 21, 2014 at 11:50 pm #

    Why is it showing only opportunity access and case access options while defining role?

    • JohnCoppedge August 24, 2014 at 11:39 pm #

      The relationship between accounts, opportunities, and cases is unique and configured in this fashion. Other objects are not influenced by their relationship to accounts in this fashion.

  54. James MacRae June 17, 2014 at 12:29 pm #

    I recently took the exam and was asked the question.

    Whats is the Salesforce default OWD for accounts?

    Could be worth researching all the OWD defaults for the exam.

  55. Frank van Meegen December 3, 2013 at 8:31 am #

    What is your best practice regarding the organization-wide defaults? E.g. do you change these settings as soon as you start a new instance? Or do you keep these settings default?

    • JohnCoppedge December 3, 2013 at 12:41 pm #

      Generally you want to figure out what security settings will apply to the whole organization and then implement them after that is fully understood. If you need a private sharing model, it is generally best to implement sharing rules first – so that when you turn off org-wide access to the object the users will already have rules in place to grant access where needed.

  56. Rennie July 25, 2013 at 1:13 am #

    In the “List and describe the standard profiles” section, you have “Solution Manager” listed twice.

Leave a Reply