Salesforce provides a flexible, layered sharing model that makes it easy to assign different data sets to different sets of users. This ensures you can balance security and convenience, minimizing the risk of stolen or misused data while making sure that all users can easily access the data they need.
Salesforce includes simple–to–configure security controls that make it easy to specify which users can view, create, edit, or delete any record or field in the app. You can configure access at the level of the organization, objects, fields, or individual records. By combining security controls at different levels, you can provide just the right level of data access to thousands of users without having to specify permissions for each user individually.
Levels of Data Access
You can configure access to data in Salesforce at four main levels.
- 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.
- 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.
- 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.
- 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. You can manage record–level access in the following ways.
- Organization–wide defaults specify the default level of access users have to each others’ records. You use organization–wide sharing settings to lock down your data to the most restrictive level, and then use the other sharing tools to selectively give access to other users. For example, you can give all employees access to an object called Candidate to allow anyone to add a candidate to the database. But you can restrict access to Positions so that anyone can see the jobs available but only the employees with the proper permissions can edit them.
- Role hierarchies open up access to those higher in the hierarchy so they inherit access to all records owned by users below them in the hierarchy. Role hierarchies don’t have to match your organization chart exactly. Instead, each role in the hierarchy represents a level of data access that a user or group of users needs. For example, you can restrict access to Candidates by setting the organization–wide default to Private, but allow recruiters to view and edit the candidate records that they own. Recruiters can’t see candidate records they don’t own because recruiters are all at the same level in the role hierarchy. However, hiring managers can be given read/write access to all candidate records because they are at a higher level in the role hierarchy than recruiters.
- Sharing rules enable you to make automatic exceptions to organization–wide defaults for particular groups of users, to give them access to records they don’t own or can’t normally see. Sharing rules, like role hierarchies, are only used to give more users access to records—they can’t be stricter than your organization–wide default settings. For example, you can allow all employees to view Positions, but use sharing rules to grant full editing access to employees in a role or group called Hiring Managers.
- Manual sharing allows owners of particular records to share them with other users. Although manual sharing isn’t automated like organization–wide sharing settings, role hierarchies, or sharing rules, it can be useful in some situations, for example, if a recruiter going on vacation needs to temporarily assign ownership of a job application to another employee.
Organization–Wide Sharing Defaults
|Private||Only the record owner, and users above that role in the hierarchy, can view, edit, and report on those records.|
|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.|
|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.