Salesforce Data Security Model Explained

    Salesforce provides a comprehensive and flexible data security model to secure data at different levels. Salesforce also provides sharing tools to open up and allow secure access to data based on business needs.

     

    There are three key constructs related to data in Salesforce: Objects, Fields, and Records. Objects are similar to tables in databases. Fields are similar to columns of the table. Records are similar to rows of data inside the table. Salesforce uses object-level, field-level, and record-level security to secure access to object, field, and individual records.

     

     

     

     

     

    Layer 1: Object-level Security

     

    Object-level access can be managed through two configurations - Profiles and Permission Sets.

     

    Profiles

    Assigning a user a profile is compulsory, as this is the place where you configure other things like page layout assignments or login IP restrictions. However, for object and field security setup, configure profiles for minimum access and use permission sets to add permissions.

     

    Permission Sets

    Permission sets are more flexible. In contrast to profiles, you can add multiple permission sets to a given user. This gives you much more flexibility at the time of designing your security model, as functionality can be grouped in more granular ways. When only using profiles, you needed to group all the object and field permissions in a single profile, for instance for a concrete job role, as sales exec. With permission sets you can have different permission sets representing the different tasks that that a sales exec performs: manage leads, approve opportunities, etc. and add or remove smaller chunks of permissions to a user at any time.

     

    Layer 2: Field-level Security

    Even if a user has access to objects, he/she still needs access to individual fields of each object. In Salesforce, profiles and permission sets also control field-level access. An admin can provide read and write permissions for individual fields. An admin can also set a field to hidden, completely hiding removing access to the field to from that user. When you hide a field with field-level security , the field won’t be accessible through any entry points (for instance via API).

     

    Layer 3: Record-level Security

    Record-level security is often referred to as the Salesforce sharing model, or just simply “record sharing” or “sharing”.

     

    Salesforce provides five ways to share records with others and access others’ records. You start by configuring org-wide defaults, to lock down your data to the most restrictive level. Then you use the other record-level security tools to grant additional access to selected users when needed.

     

     

    Types of Record-level Security

     

    1. Record-level-security: organization-wide sharing defaults

      In Salesforce, records have a field called “OwnerId” that points to a real user. Owners of records are usually people who created the record and have full CRUD (create, read, update, delete) access to it.
       

      Organization-wide defaults (OWD) control the default behavior of how every record of a given object (for example, Accounts) is accessed by users who do not own the record.


      For example:

      If OWD for Accounts is Private, then the user can only see records he/she is an owner of.
      If OWD for Accounts is Public Read Only, then any user can read (but not update or delete) the record.
      If OWD for Accounts is Public Read/Write, then it means anyone can read and update (but not delete) the record.


       
    2. Record-level-security: role hierarchies

      Typically in an organization, different job roles have different record access requirements. Normally job roles are sorted in a hierarchical way: users with a higher role should have access to records to which users in lower roles have access. Note that a role hierarchy rarely maps to an org chart. It really maps hierarchies of data access. Salesforce provides an easy way to share records with managers and represent a role hierarchy. To use this sharing rule, an admin must first add the user to a role and grant access.
       

    3. Record-level-security: sharing rules

      Hierarchy-based sharing only works for sharing upward and in a vertical direction. What if we want to share laterally? For example, what if we want to share records that a user owns with his/her peers in the same team? This is where sharing rules come in. Sharing rules provides a way to share records laterally and in an ad-hoc fashion via public groups. Let’s look into the details.
       

    • Ownership-based Sharing Rule
      Ownership-based sharing rules let admins share records based on role, role-and-subordinate, and public group ownership.
       

    • Criteria-based Sharing Rule
      Criteria-based sharing rules let users access records based on the value of a field in a record, irrespective of who owns the record.

       

    1. Record-level-security: manual sharing
       

      Manual sharing provides a mechanism to share individual records with others. This permission is accessed through the Sharing button on the record details page, and lets end-users share individual record with others.

      Please Note: This is only available if the OWD is private or public read-only because otherwise (say public read/write), you wouldn’t need it.

       

    2. Record-level-security: Apex managed sharing

      There are occasions when you can’t share records via UI or settings, but you need to write Apex code to do so.

     


    Tags

    Administration

    « Previous ArticleNext Article »