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