Organization-wide Sharing Defaults (OWD)

Organization-wide sharing settings are used to define the default sharing settings for an organization. For most objects, organization-wide sharing settings can be set to Private, Public Read Only, or Public Read/Write.

Organization-wide sharing default settings, often referred to in Salesforce CRM as OWDs, specify the default level of access to records and can be set separately for most of the objects in Salesforce such as accounts, contacts, activities, and so on.

As shown in the preceding diagram, along with the user's profile, the OWD defines the baseline level of access to data records that users do not own. The diagram represents the visibility or data access which is increasing as the other features are incorporated to provide wider sharing settings.

To customize your OWD settings, follow the path Your Name | Setup | (Administration Setup) | Security Controls | Sharing Settings. Now click on Edit in the Organization-Wide Defaults area and then for each object, select the default access you want:

Organization-wide Sharing Defaults (OWD)

OWD access level actions

The Organization-wide default (OWD) access levels allow the following actions to be applied to object records:

Access Level

Action

Public Full Access (Option for setting the Campaign object only)

Change ownership of record

 

Search records

 

Report on records

 

Add related records

 

Edit details of record

 

Delete record

Read / Write / Transfer (Option for setting the Lead and Case objects only)

Change ownership of record

 

Search records

 

Report on records

 

Add related records

 

Edit details of record

 

Read / Write

Search records

 

Report on records

 

Add related records

 

Edit details of record

 

Read Only

Search records

 

Report on records

 

Add related records

 

Private

No searching

 

No reporting

 

Public Full Access (Campaigns only)

Access levels for the Campaign OWDs can be set to Private, Public Read Only, Public Read/Write, or Public Full Access. When Campaigns are set to Public Full Access, all users can view, edit, transfer, delete, and report on all campaign records.

For example, in the scenario where John is the owner of a campaign, all other users in the application can view, edit, transfer, or delete that campaign.

Note

This option is available only for campaigns.

Public Read/Write/Transfer (Cases or Leads only)

Access levels for Case or Lead OWDs can be set to Private, Public Read Only, Public Read/Write, or Public Read/Write/Transfer. When Case or Leads are set to Public Read/Write/Transfer, all users can view, edit, transfer, and report on all case or lead records.

For example, if Lucy is the owner of WidgetX case number 101, all other users can view, edit, transfer ownership, and report on that case. But only Lucy can delete or change the sharing on case 101.

Note

This option is available only for cases or leads.

Public Read/Write

All users can view, edit, and report on all records.

For example, if Mike is the owner of the Account record Emerald Inc., all other users can view, edit, and report on the Emerald Inc. account. However, only Mike has the ability to delete the Emerald Inc. account record or alter the sharing settings.

Public Read Only

All users can view and report on records but they cannot edit them. Here, only the record owner and users above that user's role in the role hierarchy can edit the records.

For example, Nicole is the owner of the Account record EuroCorp Inc. and Nicole is in the role International Sales, reporting to Julia, who is in the role VP of International Sales. In this scenario, both Nicole and Julia have full read/write access to EuroCorp Inc.

Now, say Mike is also in the role International Sales, however, with the Public Read Only setting he can view and report on the EuroCorp Inc.account record, but cannot edit or delete it.

Private

Only the record owner, and users above that role in the hierarchy, can view, edit, and report on those records.

For example, if Mike is the owner of an Account record, and he is assigned to the role of International Sales, reporting to Julia, who is in the VP of International Sales role, then Julia can also view, edit, and report on Mike's accounts.

No Access, View Only, or Use (Price Book only)

Access levels for the Price books OWDs can be set to either No Access, View Only, or Use. Use is the default access level and allows all users to access the Price Book information as well as using the Price Book configuration for Opportunities with Products. View Only allows users to access Price Book information but not to use that Price Book detail in Opportunities with products. No Access restricts users from accessing information for Price Books and Prices.

Note

This option is available only for Price Books.

Granting access using hierarchies

By default, Salesforce uses hierarchies, like the role or territory hierarchy, to automatically grant record access to users above the record owner in the hierarchy.

This automatic granting of access to user's data to other users higher up in the Salesforce CRM hierarchy can be disabled for custom objects using the Grant Access Using Hierarchies checkbox. When this checkbox is not selected, only the record owner and users granted access by the organization-wide defaults gain access to the records.

Here we see the options available for setting some sample custom objects where, for the custom object Country, we have set the default access to Public Read Only and the Grant Access Using Hierarchies setting is checked:

Granting access using hierarchies

Controlled by Parent

When Controlled by Parent is set on an object a user can perform an action (such as view, edit, or delete) on the record based on whether they can perform that same action on the parent record associated with it. For example, if a contact record is associated with the WidgetX account using Controlled by Parent, then a user can only edit that contact if they can also edit the WidgetX account record.

When a custom object is on the detail side of a master-detail relationship with a standard object, its organization-wide default is automatically set to Controlled by Parent and it is not editable, as shown for the custom objects Account Last View and Activity Tracker:

Controlled by Parent

Note

Although Grant Access Using Hierarchies can be deselected to prevent users that are higher in the role or territory hierarchy having automatic access, users with the View All and Modify All object permissions and the View All Data and Modify All Data profile permissions can still access records they do not own.

Organization-wide defaults need to be defined separately for any custom objects that are created in the Salesforce CRM application.

For some standard objects, you cannot actually change the organization-wide sharing default setting.

For example, the Organization-Wide Default (OWD) for the Solution object in Salesforce is preset to Public Read/Write which cannot be changed.

You can use organization-wide defaults to set the default level of record access for the following standard objects where the default organization-wide sharing settings are:

Object

Default Access

Accounts

Public Read/Write

Activities

Private

Assets

Public Read/Write

Calendar

Hide Details and Add Events

Campaigns

Public Full Access

Cases

Public Read/Write/Transfer

Contacts

Controlled by Parent

Contracts

Public Read/Write

Custom Objects

Public Read/Write

Leads

Public Read/Write/Transfer

Opportunities

Public Read Only

Price Books

Use

Service

Contracts Private

Granting users additional access

Where the Organization-wide default (OWD) setting for an object is Private or Public Read Only, you can grant users additional access to records with the use of Permission Sets, role hierarchies, and sharing rules.

Note

Sharing rules and Permission Sets can only be used to grant additional access and cannot be used to restrict access to records from what was originally specified with the Organization-wide default (OWD).

Permission Sets

Permission Sets allow you to further control access to the system for the users in your organization. They can be considered as a method to fine-tune the permissions for selected individuals and enable access in a similar way to the setting up of profiles.

While an individual user can have only one Profile, you can assign multiple permissions and Permission Sets to users. For example, you can create a permission called Convert Leads that provides the facility for converting and Transfer of Leads and assign it to a user who has a profile which does not provide Lead Conversion. You can also create a permission called Access Widget which is associated to a custom object called Widget that is set in the Organization-wide defaults (OWD) as Private. Here, you can assign it to a user who has a profile which does not include the ability to access Widgets through their profile settings.

It is a two step process to setup Permission Sets for users which includes:

  1. Create the Permission Set from the Permission Set edit page.
  2. Assign the User to the Permission Set from the User edit page.

Creating the Permission Set from the Permission Set edit page

To view and manage your organization's Permission Sets, follow the path Your Name | Setup | (Administration Setup) | Manage Users | Permission Sets. For a new Permission Set, click on the New button, complete the sections: "permission set information" and "Select the type of users who will use this permission set". Now edit the Object and Field Permissions and choose the required object.

The following screen shows the creation of a Permission Set that allows Users to Access the Widgets object (which is set to Private in Organization-wide default (OWD) access model).

Creating the Permission Set from the Permission Set edit page

Assigning the User to the Permission Set from the User edit page.

To view and manage which of your User's are assigned to Permission Sets, follow the path Your Name | Setup | (Administration Setup) | Manage Users | Users. Now choose a user by clicking on their Username. Click on Permission Set Assignments and then Edit Assignment to view and select from the list of available permissions. The following screen shows the resulting section:

Assigning the User to the Permission Set from the User edit page.

Tip

You can create up to 1,000 permission sets for your organization.

You can group multiple permissions into a Permission Set to create specific profile-like permissions without actually having to create or clone complete profiles which are often unnecessary and time-consuming.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.191.253.62