TO SHARE OR NOT TO SHARE – PART 1

Part 1 – Organization-Wide Defaults

All of us are likely familiar with the phrase, “Sharing is caring”. Whether you are in preschool and your teacher asks you not to play with all the toys at once or you are in a corporate environment waiting for the microwave to free up, you realize sooner or later that if you want to “play in the sandbox”, you are going to have to learn to share well. And then, once you have reached that landmark, you start sharing everything —  time, resources, information, ideas, and eventually, your precious Salesforce records. Because sharing our data is in fact, the greatest asset one can share!

Make a Plan for Effective Sharing

Before you embark on this great sharing adventure, here are some tips and tricks to consider.

When it comes to sharing Salesforce Records, first ask yourself these three key questions:
1. What am I sharing? This refers to objects — Account, Opportunity, Lead, etc.
2. With whom am I sharing my data? These are the user(s), group(s) or role(s).
3. Why should my data be shared with them? This is the business case or strategy behind sharing records.

At the end of the day, sharing data in the CRM world is about empowering and collaborating with people, not about cluttering their views, searches, reports, and giving them access to records they should not see. With an effective strategy in place for viewing and sharing your data, you will set yourself and your team up for major success. A win-win for everybody!

untitledArchitect Your Success

In Salesforce, there is a sharing architecture in place that allows you to restrict or open up access to records. All of this begins at the core, the Organization-Wide Defaults or OWD. This is where you define the base level of access all your users will have by default per object.

There are four possible settings:
1. Public Read/Write
2. Public Read Only
3. Private
4. Controlled By Parent

By default, a new Salesforce Org will come wide open; this means ALL its core objects (accounts, contacts, opportunities, leads, case, campaign, so on) are set to “Public Read/Write”, as well as any custom object.

If you’d like to change the OWD values, follow these steps:
1. From the Setup Menu,
2. Type “Sharing Settings” on the quick Find,
3. Click Edit.

screen-shot-2016-11-15-at-12-41-24-pm

Before you change anything, let’s consider the impact of each OWD setting:

  • Public Read/Write: This means anyone, regardless of their Role or Ownership status, will be able to see and edit all records of the object. This setting is ideal for objects where a high level of collaboration is needed.
  • Public Read-Only: Is best used when the business requirement mandates that anyone can see the record, but ONLY the owner of the record can edit it.
  • Private: This is the most restrictive setting of all. If your company is a medium-to-large sized company with regional divisions OR if your company is international, this will probably be a setting you choose. This setting only allows the Owner to view and edit their records.
  • Controlled By Parent: This setting will only show for the Detail or Child record on a Master-Detail relationship. This function means that whoever has access to the Master or parent record will also have access to the detail record.

Choose the Correct OWD Settings for your Objects

The rule of thumb is to make your OWD as restrictive as needed. For example:

  • If anyone (even a single user) should not be able to view a record for a specific object, then the OWD setting should be Private.
  • If everyone should see everyone else’s records, but should not be able to edit them, then the OWD setting should be Public Read-Only.
  • Finally, if everyone should be able to view and edit one another’s records, then the OWD setting should be set to Public Read/Write.

Now, you are off and running. Sharing is indeed caring.

In Part 2, we will discuss how to open access once the OWD has been set to Private or Public Read-Only.

 

photo-clara-perez

About the Author
Clara Perez is a Salesforce MVP and Lead Developer at Great Wave who loves teaching Salesforce concepts.