Thursday, May 29, 2014

What is Organization-Wide Defaults(OWD) in salesforce?

What is Organization-Wide Defaults(OWD) in salesforce?

Organization-Wide Defaults, or OWDs, are the baseline security you for your Salesforce instance. Organizational Wide Defaults are used to restrict access. You grant access through other means we will talk about later (sharing rules, Role Hierarchy, Sales Teams and Account teams, manual sharing, etc).

There are four levels of access that can be set:
  • Public Read/Write/Transfer (only available of Leads and Cases)
  • Public Read/Write
  • Public Read/Only
  •  Private 
To reduce the number of variables in this discussion let’s collapse the three “Public” flavors to a single bucket and frame the discussion around the impact of changing your OWDs from “Public” to “Private.” As we mentioned before, Organization-Wide Defualts are used restrict access, not grant access. If you need to restrict access to even one individual out of a 1,000 Users, the only way to do that is to set your Organizational Wide Defaults to “Private,” and grant access back to everyone else but that single User you need to keep in the dark.
Shields up!
What does setting your OWDs to “Private” really do? The best way to explain this concept is with an org chart. A traditional Org Chart would look cleaner, but let’s look use the Role Hierarchy diagram shown in “Tree View” since it’s available inside

When you flip an Object in your OWDs to “Private” you’ve in essence erected walls between users in the same level of the Role Hierarchy. To illustrate using my diagram below, the restricted access walls set by the flipping an Object to “Private” are represented by the dashed green, red and blue lines. For the Object set to “Private,” the Users in the Role ofEastern Sales Team can no longer see records owned by the Western Sales Teambecause they are at the same level of the Role Hierarchy (looking “across” the same level is represented by the solid blue, red and green double headed arrows in the diagram below). The same is true the next level up in the Role Hierarchy. The Users in the role Director, Direct Sales cannot see records owned by the Director, Channel Sales.  Not surprising, access continues to be limited up the ladder across the same tiers of the Role Hierarchy. OurVP, North America Sales, the VP, Marketing and the VP, International Sales cannot see records owned by their peers, nor can they see the records owned by their peer’s subordinates. If you can’t look across, then you can’t look across and then down – e.g. theDirector, Direct Sales cannot see the records owned by the Channel Sales Team(because they are a subordinate to the Director, Direct Sales peer, the Director, Channel Sales).

Here is where the Role Hierarchy grants access in a Private setting. Manager’s (meaning, Users that have a higher position in the Role Hierarchy) can always see the records owned by their role subordinates. Using our diagram again, access granted by the Role Hierarchy is represented by the curved pink, yellow and blue lines. The SVP, Sales & Marketing can see the records owned by his role subordinates – the VP, North America SalesVP, Marketingand the VP, International Sales. Not surprising the VP, North American Sales can see records owned by the Director, Channel SalesDirector, Direct Sales and down the Role Hierarchy to their direct reports – the Channel Sales Team, the Western Sales Team and the Eastern Sales Team.

On an Object with its OWDs set to “Private,” the Role Hierarchy grants access down to subordinate roles’ records, but does not grant access upward. For example, The Western Sales Team cannot see records owned by their manager the Director, Direct Sales(because it is one level up the Role Hierarchy).

The impact to Reports, Views, Search and Lookups
NOTE: If a User cannot see a record due to security settings, that restriction cascades throughout Meaning, that User will not see the record using Search, Views on Tabs, Reports, and Lookups.


Post a Comment

| ,