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