Levels of Data Access
Controlled by Parent
A user can perform an action (such as view, edit, or delete) on a contact based on whether he or she can perform that same action on the record associated with it.
Public Read-only
All users can view and report on records but not edit them. Only the owner, and users above that role in the hierarchy, can edit those records.
Public Read/Write
All users can view, edit, and report on all records.
Organization
At the highest level, you can secure access to your organization by maintaining a list of authorized users, setting password policies, and limiting login access to certain hours and certain locations.
Objects
Object-level security provides the simplest way to control which users have access to which data. By setting permissions on a particular type of object, you can prevent a group of users from creating, viewing, editing, or deleting any records of that object. For example, you can use object permissions to ensure that interviewers can view positions and job applications but not edit or delete them.
Private
Only the record owner, and users above that role in the hierarchy, can view, edit, and report on those records.
You can configure access to data in Salesforce at four main levels.
Organization Object Field Record
You can manage record-level access in the following ways.
Organization-wide defaults Role Hierarchies Sharing Rules Manual Sharing
Before configuring record access, you might find it useful to answer the following questions
Should your users have open access to every record, or just a subset? If it's a subset, what rules should determine whether the user can access them?
Records
To control data with greater precision, you can allow particular users to view an object, but then restrict the individual object records they're allowed to see. For example, record-level access allows interviewers to see and edit their own reviews, without exposing the reviews of other interviewers.
Overview of Record-Level Security
You can control data access with greater precision by allowing particular users to view an object, but then restricting the individual records within the object they're allowed to see. For example, you can use organization-wide defaults to set access for reviews to Private. You can then use role hierarchies to grant interviewers edit access to reviews that they own.
Fields
You can use field-level security to restrict access to certain fields, even for objects a user has access to. For example, you can make the salary field in a position object invisible to interviewers but visible to hiring managers and recruiters.
you can only use sharing rules to
grant more access—they cannot be used to restrict access to records beyond what was originally specified with the organization-wide sharing defaults.
organization-wide defaults
hese are the defaults that specify the baseline level of access that users have to records that they don't own. Configure your organization-wide defaults for what the most restricted user is allowed to access. Then use other record-level security and sharing tools (role hierarchies, sharing rules, and manual sharing) to open up the data to other users who need to access it.
In environments where you've set the organization-wide sharing setting for an object as Private or Public Read Only, you can grant users more access to records by
setting up a role hierarchy or defining sharing rules.
You can specify the default level of access to records for each type of
standard or custom object. You can never use organization-wide defaults to grant users more access than they have through their object permission