Organization-wide Defaults (OWD)

 Organization-wide Defaults are used to lock down data records for specific objects.

Each object will be assigned a level and these can be different for an internal versus external users.

Access will then be opened up to other users or groups using a mixture of manual sharing. sharing roles, and the role hierarchy.

Access Levels :

1.Private 

Private is the most restrictive level of access and this means that only the record owner and any users above them in the role hierarchy 

can view, edit, or report on those records. In other words, only managers can see the records of their employees. 

2.Public read-only

Public read only indicates that all users can view and report on records, but only the owner and their managers can actually edit the record, 

and remember all this is still dependent on whether users have the appropriate object level permission.

3.Public read/write

Public read/write access means that all users can view, edit, and report on all records. 

So this is kind of the least restrictive level of access and this one should only be assigned after really careful consideration.

4.Public read/write/transfer

Public read/write/transfer is a special level that is only available to lead and case objects and since those are the only kinds of 

accounts that allow for a transfer to happen.

Grant Access Using Hierarchies

By default, the Grant Access Using Hierarchies option is enabled for all objects, and it can only be changed for custom objects.

This is checked for all objects by default, but important thing to remember, admins can uncheck this box for custom objects only.

Note :

org-wide defaults are the only way that you have to limit record access for users.

Access Grants :

Access grants start with the org-wide default level for each object.

And when they are set to private or read only, an access grant is assigned, and this determines how much access a user or group has to that object's records. 

And that leads us to what those access grant types can be.

Note : Access grants determines how records can be accessed.

1.Explicit grants

Explicit grants happen when a user becomes the owner of a record or a user 

shares a record using one of the sharing tools that I already mentioned.

 

2.Group Membership grants

Group membership grants occur when an explicit grant is directly assigned to a member of a group, queue, role, or a territory.

3.Inherited grants

Inherited grants happen when a user inherits access because they are part of some group or hierarchy. 

This comes into picture when user get access to records because of role hierarchy, territory hierarchy or inherit access through group hierarchy.

4.Implicit Grants

Think of this as Salesforce's built-in sharing. It just applies to objects that have a parent-to-child relationship. 

Sharing database Architecture :

Salesforce store access grants in three types of tables:

1.Object Record Tables

This table indicate which user, group or queue own each record.

2.Object Sharing Tables

This table store information like which record is shared with which user or group either by apex manage sharing rule 

or declarative sharing when object OWD is not PUBLIC READ/WRITE.

This table store data that supports explicit and implicit grants.

3.Group Maintenance Tables

This table store data that supports group membership grants and inherited grants. 

Role Hierarchy :

Represents group of managed users.

Managers have same access as employees.

Peers do not share access to records.

Note : Poorly designed role hierarchies can have big impact on org maintenance and performance.