Salesforce Data Security is about securing or sharing data settings and visibility between users or groups of users across the organization. The Force.com platform offers a flexible hierarchical sharing model that can easily assign different data sets to different sets of users.
The Security and Sharing model can be fully configured using the user interface but is implemented at the API level, which means that even if users query or update data via API calls, any permissions specified for objects, records, and fields apply.
With the Salesforce platform’s flexible hierarchical sharing model, different sets of data can easily be assigned to different sets of users. You can strike a balance between security and convenience, reduce the risk of data theft or misuse, and ensure that all users can easily access the data.
The platform makes it easy to specify which users can view, create, edit, or delete any record or field in the app.
You can control access to your whole org, a specific object, a specific field, or even an individual record. 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 control which users have access to which data in your whole org, a specific object, a specific field, or an individual record.
Organization
For the entire organization, you can maintain a list of authorized users, set password policies, and restrict login to specific times and locations.
Objects
Object-level data access is the easiest thing to control. By setting permissions on a specific type of object, you can prevent a group of users from creating, viewing, editing, or deleting any records on that object. For example, you can use object permissions to ensure that interviewers can view jobs and job forms, but cannot edit or delete them. You can use configuration files to manage the objects that users can access and their permissions for each object. You can also use permission sets and permission groups to extend access rights and permissions without modifying user profiles.
Fields
Even if the user has access to the object, you can restrict access to certain fields. For example, you can set the salary field as a location object that is not visible to interviewers, but to managers and recruiters.
Records
One can allow specific users to review the associated grade object, and then again restrict the individual records of the object that they are allowed to check. For example, the associated grade interviewer will see and edit her own reviews, but not the reviews of alternate interviewers. will manage record-level access for these four forms of access.
Organization-Wide Defaults specify the default level of access users have to each others’ records. You use org-wide sharing settings to lock down your data to the most restrictive level, and then use the other record-level security and sharing tools to selectively give access to other users.
Role hierarchies give access for users higher in the hierarchy 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 should represent a level of data access that a user or group of users needs.
Sharing rules are automatic exceptions to organization-wide defaults for particular groups of users, so they can get to records they don’t own or can’t normally see. Sharing rules, like role hierarchies, are only used to give additional users access to records. They can’t be stricter than your organization-wide default settings.
Manual sharing allows owners of particular records to share them with other users. Although manual sharing isn’t automated like org-wide sharing settings, role hierarchies, or sharing rules, it can be useful in some situations, such as when a recruiter going on vacation needs to temporarily assign ownership of a job application to someone else.
Please click this link to read more about this topic.
