This video brought to you by at Salesforce docs! Welcome to Organization-Wide Defaults,
the fourth in the Who Sees What series. These videos provide the basics on visibility and
data access in Salesforce. Now that we’ve given individuals at AW Computing
access to the organization and objects, it's time to think about the baseline level
of visibility we want for each object, across the entire org. When we created our Inside
Sales Rep profile, we set up the following permissions for records the reps own: Accounts
Create and Read. We don’t want inside sales reps to edit or delete accounts Contacts
– Create, Read, Edit and Delete. So inside sales reps CAN update information when talking
to customers. Opportunities Inside Sales Reps have Create,
Read, Edit but not Delete, since we don’t want reps deleting opportunities.
Cases – we left the default settings of Create, Read, Edit, Delete
These are the settings for the records that each inside sales rep owns.
But what about records they don’t own? Do we want them to have the ability to edit and
delete each other’s contacts? Or to read and edit each other's opportunities?
The organization wide defaults for sharing settings determine what access and permissions
users have to records they don’t own. Let’s look at some of the options:
Public Read Write Transfer allows non-owners to view, edit and change ownership. This public
ability to transfer ownership only applies to Leads and Cases. For all other standard
objects, only the owner or someone above them in the role hierarchy can transfer ownership.
In this example, users can view, edit, and change ownership of Leads they don’t own.
You can make records of an object Public Read/Write. Here, users can view and edit Accounts, Contracts
and Assets they don’t own, but they can’t transfer ownership.
Public Read Only means users can view all the records of an object, but they can’t
edit them or transfer ownership. In this example, users can see Contacts they
don’t own, but they can’t edit or transfer them.
The most restrictive setting is Private Here, users can’t even see opportunities
they don’t own. Let’s setup the default sharing settings
for AW Computing. Sharing Settings are also known as “Org-wide
defaults” or OWD. They’re located in Setup, under Security.
Sharing Settings Here we’ll set the default access level
to each object for the entire organization. Right now, access to all objects is completely
open. This column, Grant Access
Using Hierarchies works with the role hierarchy, which we cover later in this video series.
Here at AW Computing, all of our employees can view and edit leads, but we only want
owners to be able to transfer a Lead to a new owner, so we set Leads to Public Read Write
All of our users should be able to view Accounts, Contracts and Assets but we don’t want users
editing each other’s records, so we make this Public Read Only.
At AW we let all users update Contacts, so we leave this as Public Read, Write.
Opportunity information is often confidential, so we set Opportunities to Private.
This means that Opportunity records are only visible to their owners, and to users above
them in the role hierarchy. Users cannot see each others Opportunities unless an opportunity
is specifically shared. Role hierarchy and sharing are covered later in this series.
We change Case access to Private as well. We leave the other settings as is, and click
Save. In a large organization, changing the sharing
settings will take some time. If you are setting up a new organization, this process will be
very quick. Now weve set the default sharing settings
for AW Computing!. When assessing how Org Wide Defaults work
in conjunction with profile permissions, remember that profile permissions determine the baseline
level of access a user has to all records. Org wide defaults can then further restrict
these permissions on records a user does not own.
Let’s use the Contact object as an example and see these settings in action with our
Inside Sales Rep, Karen Adams. If the permissions are Create, Read, Edit,
Delete and the org-wide default is set to private,
Karen can create new records, she can only see Contacts that she owns, and
on those records, she has Edit and Delete permissions.
If we reduce the permissions to Create and Read and leave the org-wide default as Private,
Karen can create new records, she can only see Contacts that she owns,
and on those records, she does not have Edit or Delete permissions.
Let's say we set permissions on her profile to Create, Read, Edit, Delete and the org-wide
default is set to Public Read Only. Karen is now able to create new Contacts,
and she can view all Contact records, even ones she doesn’t own.
However, use of the Edit and Delete buttons on Contacts Karen does not own results in
an Insufficient Privileges message, because the org-wide defaults are Public Read
Only. She can, of course, Edit and Delete contacts
she does own. If we leave the org-wide default the same,
and remove all object permissions, even Read then Karen isn’t able to view any contact
records anywhere in the system. Nor can she find them by searching, or through reports.
In our last example, well set the permissions to Create, Read, Edit, Delete and the org-wide
default to Public Read/Write then Karen can create new contacts.
She can view Contacts she does not own as well as her own,
and she has Edit and Delete permission on all Contacts.
If we reduce her permissions to Create and Read, and keep the org-wide default the same
she can create new contacts, however the Edit and Delete buttons aren’t available
on any contact records. Remember org wide defaults can never grant
users MORE access than they have through their object permissions.
To learn more about visibility and access, check out all the titles in this video series.
You can also search for these topics in Salesforce Help
And come join us on the trail at trailblazer dot salesforce dot com