Skip to main content
All CollectionsSalesforce How-Tos and Best Practices
Restrict Reps to Only See Accounts and Opportunities they Own
Restrict Reps to Only See Accounts and Opportunities they Own
Andrew Tzikas avatar
Written by Andrew Tzikas
Updated over a week ago

Article Audience: System Administrator

Prerequisite you must be a System Administrator to take these steps

One of the great things with Salesforce is that is highly customizable, but with great power comes great responsibility, and if you're looking to move to an operating model where you want to restrict Reps to only see the Accounts and Opportunities that they own, you will need to adjust your settings accordingly.

It all starts with Organizational Wide Defaults (OWD)

OWDs, are settings that define the default level of access and visibility for records in a Salesforce organization. These settings establish the baseline security and privacy rules for various types of data within the system. You cannot restrict access beyond the baseline OWD that is set. Other sharing setting such as Permission Sets can only extend IE open access to users pertaining to Fields, Records, Objects, etc.
โ€‹
Org Wide Defaults are a fundamental part of Salesforce's security model and play a crucial role in controlling who can see and edit records.

Here's the three key concepts related to Salesforce Org Wide Defaults:

  1. Objects: In Salesforce, data is organized into objects, which represent different types of information (e.g., Accounts, Contacts, Opportunities). Each object can have its own OWD settings.

  2. Access Levels: Org Wide Defaults determine the default access levels for records of a specific object. The primary access levels include:

    • Private: Only the record owner and users with higher-level access can view and edit the record.

    • Public Read-Only: All users can view records, but only the owner and higher-level users can edit them.

    • Public Read/Write: All users can view and edit all records of the object.

  3. Hierarchy: In addition to the basic access levels, Salesforce allows for a more nuanced access control called "Role Hierarchy." This feature lets users in higher roles access records owned by users beneath them in the hierarchy, even if OWD settings are set to "Private."

Other parts of the OWDs pertain to Sharing Rules and Manual Sharing settings that are out of scope for this Help Center Article Use Case.

How to Set Up OWDs for the Account and Opportunity Object:

  1. Go to Setup (Cog Wheel Icon)

  2. Search for Sharing Setting in the Quick Find Box

  3. Once in Sharing Settings, click "Edit"

  4. Locate both the Account and Opportunity row and set it to "Private"

Update Permission Sets in Permission Set Group

If you have installed Swantide's Set Up Package, there are a couple things to check for. The first thing is to check the Permission Set called "Change_standard_object_ownership " which can be located in two places.

The first location to check is if its been added to the Permission Set Group. To check for this, go to Setup and Search "Permission Set Group"

Once in the Permission Set Group window, locate "Swantide_Standard_User" and click on it.

When you are in the Permission Set Group "Swantide_Standard_User" , click on "Permission Sets in Group"

Then locate the Permission Set called, "Change_standard_object_ownership". If you don't see it skip this step and go to Locating the Permission Set not within a Permission Set Group

Click on that Permission Set, Click "Object Settings" under "Apps"

Locate Account and Opportunity under Object Settings. Uncheck "View All" and "Modify All "

Click Save, and repeat the process for any other objects in Scope.

Locating the Permission Set not within a Permission Set Group

If you didn't see see the Permission Set "Change_standard_object_ownership" still verify that no users are assigned to the Permission Set. To do so, search for "Permission Sets" in the Quick Find box in Setup.

Once in Permission Sets, locate "Change_standard_object_ownership"

Click on Manage Assignments

If the list returns as blank, that means two things:

  1. No users are directly assigned to this Permission Set

  2. Or you have users assigned to it via a Permission Set Group

    1. So as best practice always double check both areas.

As Best Practice, before changing Record and Object Security Settings, always perform changes in Sandbox first. Once tested, then promote these changes to Production.

Always communicate with end users on when changes are coming.

Did this answer your question?