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 access to the organization, and access to objects,
its time to think about the baseline level of visibility we want, for each object, across
the entire organization.
At AW Computing when we created our Inside Sales Rep profile, we set up the following
permissions: 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 correct 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 others 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 read, 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 cannot
transfer ownership.
Public Read Only means users can view all the records of an object, but they cannot
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 cannot see opportunities they
do not 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 the Setup pages, <> under Security Controls
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’ll 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’ll
make this Public Read Only.
At AW we let all users update Contacts, so we’ll leave this as Public Read/Write.
Opportunity information is often confidential, so we’ll 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 other’s Opportunities unless an opportunity is specifically shared.
Role hierarchy and sharing are covered later in this series.
We will change Case access to Private as well.
We’ll 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.
And we’ve set the default sharing settings for AW Computing!.
When assessing how Org Wide Defaults work in conjunction with profile permissions, its
important to remember that 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.
Lets say we have set permissions on her profile to Create, Read, Edit, Delete and the org-wide
default is set to Public Read Only.
Karen will be able to create new Contacts, and she will be able to view all Contact records,
even ones she doesn’t own.
However, use of the Edit and Delete buttons on Contacts Karen does not own will result
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 will not be able to view any contact records anywhere in the system.
Nor can she find them by searching or through reports.
Remember, Org-Wide defaults can never grant users MORE access than they have through their
object permissions."
In our last example, we’ll set the permissions to Create, Read, Edit, Delete and the org-wide
default to Public Read Write.
then Karen be able to create new contacts she will see be able to view Contacts she
does not own as well as her own, And she will have 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 will be able to create new contacts however
the Edit and Delete buttons are not available on any contact records.
Remember, org wide defaults can never grant users MORE access than they have through their
object permissions.
For more information on the topic of visibility and access, please watch the rest of this
video series.
In addition, you can search for these topics in Help & Training.
Thanks for using Salesforce!