In the article by Rakesh Gupta and Sagar Pareek, authors of Salesforce.com Customization Handbook, we will discuss Organization-Wide Default (OWD) and various ways to share records. We will also discuss the various security settings in Salesforce. The following topics will be covered in this article:

(For more resources related to this topic, see here.)

• Concepts of OWD
• The sharing rule
• Field-Level Security and its effect on data visibility
• Setting up password polices

Concepts of OWD

Organization-Wide Default is also known as OWD. This is the base-level sharing and setting of objects in your organization. By using this, you can secure your data so that other users can’t access data that they don’t have access to. The following diagram shows the basic database security in Salesforce. In this, OWD plays a key role.

It’s a base-level object setting in the organization, and you can’t go below this. So here, we will discuss OWD in Salesforce.

Let’s start with an example. Sagar Pareek is the system administrator in Appiuss. His manager Sara Barellies told him that the user who has created or owns the account records as well as the users that are higher in the role hierarchy can access the records.

Here, you have to think first about OWD because it is the basic thing to restrict object-level access in Salesforce. To achieve this, Sagar Pareek has to set Organization-Wide Default for the account object to private.

Setting up OWD

To change or update OWD for your organization, follow these steps:

1. Navigate to Setup | Administer | Security Controls | Sharing Settings.
2. From the Manage sharing settings for drop-down menu, select the object for which you want to change OWD.

3. Click on Edit.
4. From the Default Access drop-down menu, select an access as per your business needs.
5. For the preceding scenario, select Private to grant access to users who are at a high position in the role hierarchy, by selecting Grant access using hierarchy. For standard objects, it is automatically selected, and for custom objects, you have the option to select it.
6. Click on Save.

The following table describes the various types of OWD access and their respective description:

OWD access	Description
Private	Only the owner of the records and the higher users in the role hierarchy are able to access and report on the records.
Public read only	All users can view the records, but only the owners and the users higher in the role hierarchy can edit them.
Public read/write	All users can view, edit, and report on all records.
Public read/write/ transfer	All users can view, edit, transfer, and report on all records. This is only available for case and lead objects.
Controlled by parent	This says that access on the child object’s records is controlled by the parent.
Public full access	This is available for campaigns. In this, all users can view, edit, transfer, and report on all records.

 

You can assign this access to campaigns, accounts, cases, contacts, contracts, leads, opportunities, users, and custom objects. This feature is only available for Professional, Enterprise, Unlimited, Performance, Developer, and Database Editions.

Basic OWD settings for objects

Whenever you buy your Salesforce Instance, it comes with the predefined OWD settings for standard objects. You can change them anytime by following the path Setup | Administer | Security Controls | Sharing Settings. The following table describes the default access to objects:

Object	Default access
Account	Public read/write
Activity	Private
Asset	Public read/write
Campaign	Public full access
Case	Public read/write transfer
Contact	Controlled by parent (that is, account)
Contract	Public read/write
Custom Object	Public read/write
Lead	Public read/write transfer
Opportunity	Public read only
Users	Public read only and private for external users

Let’s continue with another example. Sagar Pareek is the system administrator in Appiuss. His manager Sara Barellies told him that only the users who created the record for the demo object can access the records, and no one else can have the power to view/edit/delete it.

To do this, you have to change OWD for a demo object to private, and don’t select Grant Access Using Hierarchy.

When you select the Grant Access Using Hierarchy field, it provides access to people who are above in the role hierarchy.

Sharing Rule

To open the record-level access for a group of users, roles, or roles and subordinates beyond OWD, you can use Sharing Rule. Sharing Rule is used for open access; you can’t use Sharing Rule to restrict access.

Let’s start with an example where Sagar Pareek is the system administrator in Appiuss. His manager Sara Barellies wants every user in the organization to be able to view the account records but only a group of users (all the users do not belong to the same role or have the same profile) can edit it.

To solve the preceding business requirement, you have to follow these steps:

1. First, change the OWD account to Public Read Only by following the path Setup | Administer | Security Controls | Sharing Settings, so all users from the organization can view the account records.

2. Now, create a public group Account access and add users as per the business requirement. To create a public group, follow the path Name | Setup | Administration Setup | Manage Users | Public Groups.
3. Finally, you have to create a sharing rule. To create sharing rules, follow the path Setup | Administer | Security Controls | Sharing Settings, and navigate to the list related to Account Sharing Rules:

4. Click on New, and it will redirect you to a new window where you have to enter Label, Rule Name, and Description (always write a description so that other administrators or developers get to know why this rule was created).
5. Then, for Rule Type, select Based on criteria.
6. Select the criteria by which records are to be shared and create a criterion so that all records fall under it (such as Account Name not equal to null).
7. Select Public Groups in the Share with option and your group name.
8. Select the level of access for the users. Here, select Read/Write from the drop-down menu of Default Account, Contract and Asset Access. Finally, it will look like the following screenshot:

Types of Sharing Rules

What we did to solve the preceding business requirement is called Sharing Rule. There is a limitation on Sharing Rules; you can write only 50 Sharing Rules (criteria-based) and 300 Sharing Rules (both owner- and criteria-based) per object. The following are the types of Sharing Rules in Salesforce:

• Manual Sharing: Only when OWD is set to Private or Public Read for any object will a sharing button be enabled in the record detail page. Record owners or users, who are at a higher position in role and hierarchy, can share records with other users. For the last business use case, we changed the account OWD to Public Read Only. If you navigate to the Account records detail page, you can see the Sharing button:

  Click on the Sharing button and it will redirect you to a new window. Now, click on Add and you are ready to share records with the following:

  • Public groups
  • Users
  • Roles
  • Roles and subordinates

  Select the access type for each object and click on Save. It will look like what is shown in the following screenshot:

  The Lead and Case Sharing buttons will be enabled when OWD is Private, Public Read Only, and Public Read/Write.

• Apex Sharing: When all other Sharing Rules can’t fulfill your requirements, then you can use the Apex Sharing method to share records. It gives you the flexibility to handle complex sharing.

Apex-managed sharing is a type of programmatic sharing that allows you to define a custom sharing reason to associate with your programmatic share. Standard Salesforce objects support programmatic sharing while custom objects support Apex-managed sharing.

Field-Level Security and its effect on data visibility

Data on fields is very important for any organization. They want to show some data to the field-specific users. In Salesforce, you can use Field-Level Security to make fields hidden or read-only for a specific profile. There are three ways in Salesforce to set Field-Level Security:

• From an object-field
• From a profile
• Field accessibility

From an object-field

Let’s start with an example where Sagar Pareek is the system administrator in Appiuss. His manager Sara Barellies wants to create a field (phone) on an account object and make this field read-only for all users and also allowing system administrators to edit the field.

To solve this business requirement, follow these steps:

1. Navigate to Setup | Customize | Account | Fields and then click on the Phone (it’s a hyperlink) field.
2. It will redirect you to the detail page of the Phone field; you will see a page like the following screenshot:

3. Click on the Set Field-Level Security button, and it will redirect you to a new page where you can set the Field-Level Security.

4. Select Visible and Read-Only for all the profiles other than that of the system administrator. For the system administrator, select only Visible.
5. Click on Save.

If you select Read-Only, the visible checkbox will automatically get selected.

From a profile

Similarly, in Field-Level settings, you can also achieve the same results from a profile. Let’s follow the preceding business use case to be achieved through the profile. To do this, follow these steps:

1. Navigate to Setup | Administer | Manage Users | Profile, go to the System Administrator profile, and click on it. Now, you are on the profile detail page.
2. Navigate to the Field-Level Security section. It will look like the following screenshot:

3. Click on the View link beside the Account option. It will open Account Field-Level Security for the profile page.
4. Click on the Edit button and edit Field-Level Security as we did in the previous section.

Field accessibility

We can achieve the same outcome by using field accessibility. To do this, follow these steps:

1. Navigate to Setup | Administer | Security Controls | Field Accessibility.
2. Click on the object name; in our case, it’s Account.
3. It will redirect you to a new page where you can select View by Fields or View by Profiles:

4. In our case, select View by Fields and then select the field Phone.
5. Click on the editable link as shown in the following screenshot:

6. It will open the Access Settings for Account Field page, where you can edit the Field-Level Security. Once done, click on Save.

Setting up password policies

For security purposes, Salesforce provides an option to set password policies for the organization. Let’s start with an example. Sagar Pareek, the system administrator of an organization, has decided to create a policy regarding the password for the organization, where the password of each user must be of 10 characters and must be a combination of alphanumeric and special characters. To do this, he will have to follow these steps:

1. Navigate to Setup | Security Controls | Password Policies. It will open the Password Policies setup page:

2. In the Minimum password length field, select 10 characters.
3. In the Password complexity requirement field, select Must mix Alpha, numeric and special characters.
4. Here, you can also decide when the password should expire under the User password expire in option. Enforce the password history under the option enforce password history, and set a password question requirement as well as the number of invalid attempts allowed and the lock-out period.

5. Click on Save.

Summary

In this article, we have gone through various security setting features available on Salesforce. Starting from OWD, followed by Sharing Rules and Field-Level Security, we also covered password policy concepts.

Resources for Article:

---

Further resources on this subject:

• Introducing Salesforce Chatter [Article]
• Salesforce CRM Functions [Article]
• Adding Geolocation Trigger to the Salesforce Account Object [Article]

---