Salesforce Developer Data Security Level Of Access

salesforce-developer-data-security

// Salesforce - Developer - Data Security - Levels of Data Access:

Org Access (IP Ranges, login hours)
  Organization-wide defaults (this should be the most restricted)
    Permission & Settings (Profiles, Permission Sets)
      Record Access (Role Hierarchy)
        Field Access

There are four main levels at which you can configure access to data on the 
platform:

1. 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.

2. 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.

3. 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.

4. 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 an 
   interviewer to see and edit her own reviews, without exposing the reviews of 
   other interviewers. You can manage record-level access in these four ways.

   1. 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 
      record-level security and sharing tools to selectively give access to 
      other users.

   2. 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 should represent a level of data 
      access that a user or group of users needs.

   3. 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 additional users access to 
      records—they can’t be stricter than your organization-wide default 
      settings.

   4. 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.

When implementing security and sharing rules for your organization, make a table 
of the various types of users in your organization. In the table, specify the 
level of access to data that each type of user needs for each object and for 
fields and records within the object. You can then refer to this table as you 
set up your security model.
en-usab1b4360799e29b571fb9fc51cd003e8.jpg
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License