• Search for:
    6May, 2024
    Data Security Model in Salesforce

    Levels of Data Access

    • Org
      1. authorized users
      2. set password policies
      3. limit logins to certain hours and locations.
      4. IP ranges
    • Object : prevent users from CRUD any records of that object.
      1. Create
      2. Read/View
      3. Update/Edit
      4. Delete
    • Field : restrict access to certain fields, even if a user has access to that object.
    • Record
      1. Organization-wide defaults
      2. Role hierarchies
      3. Sharing rules
      4. Manual sharing

    Controlling Data Access with the Salesforce Platform

    Layer 1: Object-level-security

    It prevents users from CRUD any records of that object.

    • Create
    • Read/View
    • Update/Edit
    • Delete

    We can set object permissions with

    • Profiles
    • Permission sets

    Users can have only one profile, but they can have multiple permission sets.

    Profile

    A user’s profile determines the objects they can access and the things they can do with any object record (such as create, read, edit, or delete).

    Managing Profiles

    Setup > Quick Find box > Profiles > Click the profile you want to view

    Create a Profile

    The easiest way to create a profile is to clone an existing profile that’s similar to the one you want to create, and then modify it.

    Setup > Quick Find box > Profiles

    Assign a Profile

    Make sure the Enhanced Profile User Interface is enabled in User Management Settings.

    Setup > Quick Find box > Users > Edit > Select profile > Save

    Permission sets

    Permission sets grant additional permissions and access settings to a user.

    Managing Permission Sets

    Setup > Quick Find box > Permission Sets >

    Best Practice

    Always use profiles to grant the minimum permissions and settings that all users of a particular type need. Then use permission sets to grant more permissions as needed. The combination of profiles and permission sets gives you a great deal of flexibility in specifying object-level access.

    Layer 2: Field-level-security

    It restricts access to certain fields, even if a user has access to that object.

    Field settings can be applied by modifying

    1. profiles
    2. permission sets
    3. Field Accessibility menu in Setup
    Restrict Field Access with a Profile
    1. Turn on Enhanced Profile User Interface

    Setup > Quick Find box > User Management Settings > Turn on Enhanced Profile User Interface

    1. Setup > Quick Find box > Profiles > Click profile want to change > Click Object Settings > Select object > Edit > Under Field Permissions, specify access you want for users with this profile > Save
    Add Field Access with a Permission Set

    Setup > Quick Find box > Permission Set > Object Settings > Select & Edit > Field Permissions > Click Manage Assignments > Select the users > Click Add Assignments > Done

    Layer 3: Record-level security

    We control record-level access in four ways.

    They’re listed in order of increasing access:

    • Org-wide defaults

    specify the default level of access users have to each other’s records

    • Role hierarchies

    ensure managers have access to the same records as their subordinates

    • Sharing rules

    automatic exceptions to org-wide defaults for particular groups of users, to give them access to records they don’t own or can’t normally see

    • Manual sharing

    record owners give read and edit permissions to users who might not have access to the record any other way.

    Set Org-Wide Defaults Sharing

    It specifies the baseline level of access that the most restricted user should have.

    Setup > Quick Find box > Sharing Settings > Edit (in the Organization-Wide Defaults area) 

    > Select the default internal access and default external access (For each object) > Deselect Grant Access Using Hierarchies (To disable automatic access using your hierarchies) > 

    Create Role Hierarchy
    • It works together with sharing settings
    • By default, the Grant Access Using Hierarchies option is enabled for all objects.
    • Setup > Quick Find box > Sharing Settings > Edit (in the Organization-Wide Defaults area) > Select/Deselect Grant Access Using Hierarchies (To enable/disable automatic access using your hierarchies) 
    • Setup > Quick Find box > Roles > click Set Up Roles (at the bottom of the page) > Add Role > Assign Users to Role 
    Sharing Rules

    Sharing Rules can be defined

    • for a single public group, role, or territory.
    • for a role plus its subordinates or for a territory plus its subordinates.

    Setup > Quick Find box > Sharing Settings >  Manage sharing settings > Choose object > Sharing Rules > New > Rule type: based on the owner / based on criteria > Select records to be shared > Select users > Select a sharing access setting > Click Save.

    Audit System
    • Record Modification Fields
    • Login History
    • Field History Tracking
    • Setup Audit Trail
    28Mar, 2023
    Improve Performance of SOQL Queries using a Custom Index

    SOQL queries must be selective, particularly for queries inside triggers for the best performance. To avoid long execution times, non-selective SOQL queries may be terminated by the system.

    Selective SOQL Query Criteria

    A query is selective when one of the query filters is on an indexed field and the query filter reduces the resulting number of rows below a system-defined threshold. The performance of the SOQL query improves when two or more filters used in the WHERE clause meet the mentioned conditions.

    Custom Index Considerations for Selective SOQL Queries

    The following fields are indexed by default:

    • Primary keys (ID, Name, and Owner fields).
    • Foreign keys (lookup or master-detail relationship fields).
    • Audit dates (such as SystemModStamp). 
    • Custom fields marked as External ID or Unique.

    A Custom Index can’t be created on these types of fields:

    • Multi-select Picklists.
    • Currency fields in a Multicurrency Organization.
    • Long text fields. 
    • Binary fields (fields of type blob, file, or encrypted text). 

     

    Examples of Selective SOQL Queries   

    To better understand whether a query on a large object is selective or not, let’s analyze some queries. For these queries, we will assume there are more than 200,000 records (including soft-deleted records, that is, deleted records that are still in the Recycle Bin) for the Account sObject.


    Query 1:

    SELECT Id FROM Account WHERE Id IN (<list of account IDs>)

    The WHERE clause is on an indexed field (Id). If SELECT COUNT() FROM Account WHERE Id IN (<list of account IDs>) returns fewer records than the selectivity threshold, the index on Id is used. This will typically be the case since the list of IDs only contains a small amount of records.


    Query 2:

    SELECT Id FROM Account WHERE Name != ''

    Since Account is a large object even though Name is indexed (primary key), this filter returns most of the records, making the query non-selective.

    Query 3:

    SELECT Id FROM Account WHERE Name != '' AND CustomField__c = 'ValueA'

    Here we have to see if each filter, when considered individually, is selective. As we saw in the previous example the first filter isn’t selective. So let’s focus on the second one. If the count of records returned by SELECT COUNT() FROM Account WHERE CustomField__c = ‘ValueA’ is lower than the selectivity threshold, and CustomField__c is indexed, the query is selective.

    Query 4:

    SELECT Id FROM Account WHERE FormulaField__c = 'ValueA'

    The following rules have to be true in order to index a Formula Field:

    • The formula contains fields from a single object only (not relationship fields).
    • The formula field doesn’t reference any non-deterministic functions (e.g. SYSDATE).
    • The formula field doesn’t reference any non-supported fields for including in indexes.  This list isn’t documented anywhere specifically (there are lots of special cases), but in Spring 12(176), createdById was non-supported, but in Summer 12 (178), it is supported.  Same story for CreatedDate.
    • The formula field doesn’t contain references to Primary Keys (e.g Id) 
    • The formula field does not use TEXT(<picklist-field>) function
    • If the formula references any Lookup fields, the field must not have the option “What to do if the lookup record is deleted?” set to “Clear the value of this field.”