Troubleshooting Salesforce Record Access

Security is an area where many questions can come up, especially in the User Acceptance Testing (UAT) phase. For example, why can a user View a record, why they cannot Edit, or why can a user Edit, however they cannot adjust an Opportunity Team related list? When troubleshooting, start with the basics and continue to review items until the root cause is identified. First, determine if things are “all or nothing” vs. “sometimes.” “All or nothing” scenarios are usually addressed within Profile Create, Read, Edit, Delete (CRED) settings and Org-Wide Defaults (OWD). “Sometimes” scenarios will cause you to look in Sharing Rules, Role Hierarchy, or Full Access.  

Before making any changes, always confirm “if you should make the update” vs. “if you technically can.” It is also critical to conduct Unit Tests and User Acceptance Tests (UATs) on any changes in a sandbox before making production changes.  

Begin with Profile settings that address Object level access and permissions. For example: 

• User cannot access the object at all
  • Check their Profile for Read access
• User can only View records but cannot Edit any records
  • Check their Profile for Edit access

If the issue isn’t addressed with Profile CRED, go to OWD. Org-Wide Default sets the baseline for record access and is restrictive with Sharing Rules opening up access. Record ownership is crucial, so make sure to keep that in mind in the following examples:

• User can only Edit their records and not records owned by other users
  • OWD is most likely Read Only as the user can see all records but cannot Edit. Check the Sharing Rules.
• User can sometimes Edit records but not all of them
  • OWD is most likely Read Only as the user can see all records. Check where they fall in the Role Hierarchy in comparison to the record Owner. Most likely, the records they can Edit are owned by themself or those below them in the Role Hierarchy. Adding a Sharing Rule can solve this scenario.

Role Hierarchy plays two parts in security setups. It is similar to but only loosely tied to an Organizational Chart as record access is the focus. The first impact is not only users who own a record will have access but also the users above them in the Role Hierarchy. A user’s manager should, in most scenarios, access the same items as their subordinates. This concept of inherited access runs up the Role Hierarchy and grants Full Access, which we’ll discuss in the next section. The second part impacts Reporting & List Views that reference “My Team.” 

• A manager in another department can View the record a subordinate owns, but they cannot Edit.
  • OWD is most likely Read Only as the manager can see all records. They do not have inherited access as they manage a different group of users in a parallel Role in the Role Hierarchy. Adding a Sharing Rule can solve this scenario.

Assuming that Profiles, Role Hierarchy, Org-Wide Defaults, and Sharing has been configured correctly. Who can edit the Account Team, Opportunity Team, or Case Team will bring Full Access into the picture. So who has Full Access to a record? Only the Owner and those above them in the Role Hierarchy. This situation can pose a challenge when someone who can Edit an Opportunity yet finds themself in a parallel Role wants to be added onto an Opportunity Team. This user must reach out to those who have Full Access, such as the record Owner and request to be added. An APEX component could be written to solve this, but before you go down that path, the process and user story need to be vetted. Is this an edge case, or can a Chatter post to the Owner meet the need?

• A user in Product Development is going to help with an Opportunity. They can View the Opportunity but cannot add themself to the Opportunity Team.
  • The Product Development user is not above the Seller; therefore, the user does not have Full Access to the Opportunity. They should reach out to the Opportunity Owner and request access

Data Administrative permissions should be used very sparingly if at all. Giving a user “Modify All Data” or “View All Data” will ignore all of the security items mentioned above allowing them to View and Edit any record or field in an object, or for the entire org. Doing this can help if a user doesn’t get into the security model due to them wearing many hats. However, it can cause more harm than good because doing so turns them into a data administrator for the respective object(s) or entire org. When testing any of these security items, make sure an end-user performs User Acceptance Testing. Never assume that since it passed testing for a system admin or someone with data admin access, it will pass for all users.  

• A user can View a field that should be hidden from them
  • Check their Profile or Permission Sets for “View All Data”
• A user can Edit a field that should be hidden or read-only for them
  • Check their Profile or Permission Sets for “Modify All Data”

To recap, always start with the basics. More often than not, it will be something simple or in an area you think is safe. Move into more involved scenarios once you rule out the basics. Check out this trailhead for more details on Data Security.