Toggle Side Panel

  • Home
  • Articles
    • All Articles
    • Blogs
    • Videos
    • Infographics
  • Consultants
    • Salesforce Product Expertise
      • Top Salesforce ConsultantsTop Salesforce Consultants
      • Marketing Cloud ConsultantsMarketing Cloud Consultants
      • Service Cloud ConsultantsService Cloud Consultants
      • Experience Cloud ConsultantsExperience Cloud Consultants
      • Analytics Cloud ConsultantsAnalytics Cloud Consultants
    • Salesforce Industry Expertise
      • Non-Profit Cloud ConsultantsNon-Profit Cloud Consultants
      • Financial Service Cloud ConsultantsFinancial Service Cloud Consultants
      • Health Cloud ConsultantsHealth Cloud Consultants
      • Commerce Cloud ConsultantsCommerce Cloud Consultants
      • Manufacturing Cloud ConsultantsManufacturing Cloud Consultants
    • Salesforce Experts by Location
      • USATop Salesforce Consultants in USA
      • IndiaTop Salesforce Consultants in India
      • AustraliaTop Salesforce Consultants in Australia
      • United KingdomTop Salesforce Consultants in UK
      • CanadaTop Salesforce Consultants in Canada
  • Webinars
  • Contact Us
  • Discussions
More options
    Sign in Sign up
    • Home
    • Articles
      • All Articles
      • Blogs
      • Videos
      • Infographics
    • Consultants
      • Salesforce Product Expertise
        • Top Salesforce ConsultantsTop Salesforce Consultants
        • Marketing Cloud ConsultantsMarketing Cloud Consultants
        • Service Cloud ConsultantsService Cloud Consultants
        • Experience Cloud ConsultantsExperience Cloud Consultants
        • Analytics Cloud ConsultantsAnalytics Cloud Consultants
      • Salesforce Industry Expertise
        • Non-Profit Cloud ConsultantsNon-Profit Cloud Consultants
        • Financial Service Cloud ConsultantsFinancial Service Cloud Consultants
        • Health Cloud ConsultantsHealth Cloud Consultants
        • Commerce Cloud ConsultantsCommerce Cloud Consultants
        • Manufacturing Cloud ConsultantsManufacturing Cloud Consultants
      • Salesforce Experts by Location
        • USATop Salesforce Consultants in USA
        • IndiaTop Salesforce Consultants in India
        • AustraliaTop Salesforce Consultants in Australia
        • United KingdomTop Salesforce Consultants in UK
        • CanadaTop Salesforce Consultants in Canada
    • Webinars
    • Contact Us
    • Discussions
    Close search
    data security in salesforce

    Best Practices for Data Security in Salesforce

    Anurag algoworks May 15, 2020
    13,084  Views

    When we deal with data security in Salesforce, we are essentially talking about securing our data from unauthorized access. There might be an environment with multiple users and we want to secure our data from unwanted users and, on the other hand, make sure the right users have complete access to them.

    There are four levels of security that can be applied on a particular record data:

    • Security at an Organisational level
    • Security at an Object Level
    • Record level Security
    • Field level Security

    1. Organisational level Security:

    When we talk about org (org short for organisation) level security, we are protecting our data at the broadest level by making sure only the right users can log into our org at the specified time. In an org where there are multiple users each with their own profile, we (as an administrator) can specify whether a particular user can log into our org or not and if yes, from where and when. We can restrict login to only specific locations by allocating IP ranges from Login IP Ranges section in particular profile. Only the IP we define here would be able to login successfully. Others would need a verification code to be entered. Also we can define the time range for which the users can login into that org. We can do it from the Login Hours section in a particular profile. We can also set password policies for a profile

    dont miss out iconDon’t forget to check out: Sharing Rules In Salesforce Security

    2. Object Level Security:

    This is the second level of security considering the user has successfully logged into the org.The simplest way to control data access is to set permissions on a particular type of object. We (as an administrator), can control whether a group of users can create, view, edit, or delete any records of that object. We can do this by setting object permissions on profiles and permission sets.

    Profiles

    When creating a new user in an org,  we are also required to give a profile to a user. Each profile has a licence associated with it which defines whether that profile has access to certain objects or not. There are certain standard profiles in Salesforce like System Administrator, Standard User, etc. We cannot change the object access levels of standard profiles. We can also create custom profiles by cloning the standard ones where we can changes the level of access to meet our requirements. The profiles define how much access a user has for a particular object ( whether view, or edit or delete). Therefore when a new user is created, we can assign him/her a profile defining a level of access for a particular object.

    Permission Sets

    There might be a scenario where certain group of users share a same profile but we want to give some additional permission to certain users of that group and not to all. One solution might be to create a different profiles for all the existing users. But more effective solution is the use of Permission sets which allows additional permission on certain features based on individual users. We can create permission sets and define additional features that certain users get and assign users to that set. Permission sets are designed to give additional access to users, but “does not” restrict them from what they already get through their profiles. 

    3. Record level Security

    If a user has access to objects, we can control which records on that object the users can see. This is by defining Record level security. The record level security can be achieved by four levels:

    • Organization wide Default (OWD)
    • Role Hierarchy
    • Sharing Rules
    • Manual Sharing

    Ownership

    All the four levels defined above relies on the concept of ownership. Ownership is basically defining who the owner of a particular record actually is. The owner of a record can always view and edit his/her records irrespective of the security we define, provided he/she has read and edit permissions on his/her profile. When we are dealing with the security levels in a record (defined above), we are actually defining whether a user who doesn’t own a record, have access to a record or not.

    1. Organization wide Default (OWD)

    These specify the default level of access users have to each other’s records. Org-wide defaults specify the baseline level of access that the most restricted user should have. We cannot restrict the records more than defined in OWDs. We can first define the least level of access by OWD that all the users should have. Then we can “open-up” the access for certain users by roles and sharing rules. To view and edit the OWD sharing, in Setup, use the Quick Find box to find Sharing Settings. The Default Internal Access column shows the default access for each object records. There are various options in them:

    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 only the owner, and users above that role in the hierarchy, can edit them.

    Public Read/Write: All users can view, edit, and report on all records.

    Controlled by Parent: A user can view, edit, or delete a record if she can perform that same action on the parent record it belongs to. This option is present on the detail object of a master detail relationship.

    2. Role Hierarchy

    If we want to share the records with the users who lie in the role above the user who owns the record, we define role hierarchy. When a user is created we have an option to define role of that user. To define Role hierarchy, enter Role in the Quick find box and select Roles. We can define roles of user based on our requirements. If a role hierarchy is defined and Grant Access Using Hierarchies column is checked in OWD settings, the users with roles above the owner can view and edit the record (If OWD is Private).

    dont miss out iconCheck out this amazing Infographic: How To Upgrade Your Business With Salesforce?

    3. Sharing Rules

    There are also defined to share records with the users based on certain rules. There are 2 types of rules the users can have:

    a. Based on certain criteria– When we want to share a record if the records meets certain criteria.

    b. Based on owner– When we want to share records based on who owns it.

    The sharing rules option is present in the Sharing Settings.

    4. Manual Sharing

    IF we want to share records with the users manually not based on any criteria, then we can use manual sharing. The owner of a record can share it with the user he wants by clicking on the Share button on that record page

    5. Field Level Security

    In some cases, we may want users to have access to an object, but limit their access to certain fields in that object. Field-level security settings control whether a user can see, edit, and delete the value for a particular field on an object. For defining FLS:

    1. Use the Quick Find box to find Profiles in Setup.
    2. Select the profile you want to change. “Standard User” will do nicely.
    3. Click Object Settings and select the object for which you want to update the field settings.
    4. Click Edit.
    5. For each field, specify the kind of access you want for users with this profile, and save your settings.

    We may also want to hide the fields from the user data. In this case we can use Page Layouts.

    Reference: Salesforce Trailhead, sfdc point

    Categories: Others, Salesforce Security
    Tagged: Data Security, Default Internal Access, Field Level Security, Manual Sharing, Object access, Salesforce, Salesforce Data, Salesforce Security, Salesforce Trailhead, Sharing Rules, Sharing Settings, Standard User, System Administrator

    Get listed your company

    Have an innovative Salesforce solution that delivers faster, smarter results?
    Join the Marketplace

    [adinserter block=”16″]

    best salesforce consultants
    best salesforce consultants
    best salesforce consultants
    salesforce consultants

    [adinserter block=”10″]

    salesforce consultants

    [adinserter block=”10″]

    salesforce consultants

    [adinserter block=”10″]

    salesforce consultants

    [adinserter block=”10″]

    salesforce consultants
    salesforce consultants

    [adinserter block=”10″]

    salesforce consultants
    salesforce consultants
    Footer Forcetalks logo

    support@forcetalks.com

    • twitterx

    Quick Links

    Advertise with Us

    Salesforce® Articles

    Dreamforce 2023

    Top Salesforce® Bloggers 2023

    Top Salesforce Consultants

    Get Listed

    Company

    Contact Us

    About Us

    Privacy Policy

    Terms & Conditions

    InsightHub

    Salesforce Blogs

    Salesforce Videos

    Salesforce Groups

    Salesforce Jobs

    © 2026 - Forcetalks ● All Rights Reserved

    Salesforce® is a trademark of Salesforce® Inc. No claim is made to the exclusive right to use “Salesforce”. Any services offered within the Forcetalks website/app are not sponsored or endorsed by Salesforce®.

    Try AuditMyCRM - It is a Salesforce CRM Audit tool which comprehensively scans your Salesforce org and gives you the list of errors or warnings you need to take care of.
    We use cookies to enhance your browsing experience. Please see our privacy policy if you'd like more information on our use of cookies.