Salesforce Security

Salesforce is a cloud-based customer relationship management platform widely used by organisations worldwide. It helps them to enhance customer interactions, optimise crucial business operations and more.

When it comes to Salesforce security, the platform offers a range of tools and best practices to protect data, manage user access, and ensure regulatory compliance.

This Salesforce security tutorial discusses, in more detail, how Salesforce prevents unauthorised access, ensures data integrity, and more.

Table of Contents

• User Management in Salesforce
• Salesforce Data Security Model 
• Object-Level Security in Salesforce
• Record Level Security in Salesforce
• Record Type in Salesforce
• Audit Trail in Salesforce
• Frequently Asked Questions

User Management in Salesforce

In Salesforce, every user has a profile, username, and password. Let’s discuss which actions a user can perform and which they cannot.

A Salesforce administrator plays a pivotal role in user management. They effectively manage user accounts within an organisation. They also create accounts, assign roles, grant permissions, and disable users as needed.

Furthermore, a Salesforce Administrator performs the following tasks:

• Edit users
• Change Passwords
• Create Custom Fields
• Fix custom links

In short, admins determine which data should be accessible to users and which privileges should be granted.

If you want to gain hands-on expertise in Salesforce and master real-time data operations, consider enrolling in a comprehensive Salesforce training program that covers SOQL, SOSL, and DML in depth.

Salesforce Data Security Model

The Salesforce security data model helps secure data at multiple levels. In general, Salesforce data is stored in three formats: fields, records and objects. 

In the database, objects act as tables. Fields are identical to columns present in the table. Records represent the data present in the table. 

Salesforce uses field-level, object-level, and record-level security to control access to fields, objects, and records.

When it comes to field-level security, even though a user can use objects, they still need access to their fields. In Salesforce, profiles will monitor access to fields. Admin will give read and write privileges for specific fields. Admin can also hide an individual field.

Object-level Security in Salesforce

Before granting user access, Salesforce admins check whether the user has the necessary privileges to view objects of that type. Object-level access can be managed using two configurations: permission sets, passwords, and profiles.

Let’s discuss them one by one.

• Profiles

Profiles control access at the field and object levels, including tabs, applications, and more.

• Passwords

Every user must enter their username and password every time they log in. Salesforce administrators configure many settings to ensure your passwords are secure and robust.

We’ll look at more about password management in Salesforce. 

• • Password Policies: Fix inconsistent password and login policies, such as specifying a deadline before which user passwords will expire and the required password strength.
  • User Password Resets: Passwords are reset for Specific users.
    
    

• Permission Sets

If an admin performs CRUD operations on campaigns, everyone on a profile can access these campaigns. The admin will use the permission set to give a particular user access.

You can use permission sets to grant additional permissions to users listed in a profile. Sometimes, administrators must establish a permission set that grants access to the campaign's object and then allocate it to the user.

You can use permission sets when you want:

1. 1. Add and remove permissions for a group of users.
   2. Include several permission sets for a user.
   3. Require permissions to generate a custom profile.

In summary, object-level security protects an object's records. Also, you can prevent users from viewing, deleting, or adding specific objects.

Record Level Security in Salesforce

Record-level security in Salesforce enables users to access certain object records. Each user owns every record they create and has full access to it. They also have access to records that have been shared with them.

You must first set your OWD (Org Wide Default) sharing settings, define a hierarchy, and create sharing rules to define record-level security.

• Sharing Rules - A deep dive

Sharing rules allow automatic exceptions to Org-wide sharing settings for a set of users. They provide access to records they do not own or view. Sharing rules allow users to access additional records.

A sharing rule is created based on the record owner or the criteria.

Example:

The record owner has an XYZ role that shares with the person who holds the ABC role. Alternatively, they can share the records with the desired person.

• • Manual Sharing:
    In some situations, it is not possible to permit access to a group of users for particular records. In that situation, only the record owner can grant the user access through manual sharing. 
    It is not automated and only provides the flexibility to share access to records that the record owner doesn’t have access to.
  • Public group
    A public group can be a combination of the following.
    • Distinct users
    • Distinct roles 
    • Distinct groups 
    • Distinct roles with subordinates
    • Distinct roles with their own subordinates
      
      The goal of building public groups is to provide access to resources for everyone in an organisation. Public groups greatly reduce time and effort.
      You should define the sharing guidelines once the group is formed. The owner of the records remains the same after sharing. Besides, you dont need to mention object names.
  • Types of Sharing Rules
    Salesforce primarily has two types of sharing rules based on the sharing of records, as follows:
    1. 1. Owner-based Sharing Rules
       2. Criteria-based Sharing Rules

1. • 1. Owner-based Sharing Rules
        
        When you want to share records that are owned by a single user with another group of users, you can use this method. 
        Real-time scenario-1
        For instance, if an employee at an MNC wants to share a file from his US office with other branches in different countries.
        Real-time scenario-2
        Consider a large department divided into several smaller sub-departments, each serving one or more product lines. While teams are assigned to various managers in the role hierarchy, they must view some of each other's records, such as opportunities or cases.
        In this scenario, the customer support team - A may be permitted to examine records owned by Customer Support Team - B under the record-ownership-based sharing rule, and vice versa.
     2. Criteria-based Sharing Rules
        
        When you want to share records that meet specific criteria, you can use the criteria-based sharing rules. 
        Real-time scenario - 1
        For example, a bank manager requests access to the details of every savings account. In such a scenario, a filter will be added to the sharing rules to ensure only saving accounts are shared with the bank manager.
        Real-time scenario - 2
        Let's take the case of a salesperson who interacted with a prospective customer who wasn't quite ready to make a purchase. The lead's status has been changed to "Unqualified."
        The customer must be persuaded to buy in this circumstance. It makes sense to employ marketing experts at this point and permit the examination of such "Unqualified" leads. In this way, the sharing rule will only allow the marketing specialists to view and interact with the required leads.
        
        
   • Salesforce Sharing Rules Components
     A sharing rule in Salesforce is made up of the following three elements:
     1. Records
        Salesforce administrators decide which records must be shared with a specific group of users. They determine whether a specific owner must share the records or only those that satisfy certain requirements.
     2. users
        Next, Administrators must decide whether user groups are based on user roles, user territories, or user communities. They can combine any of the following when creating public groups:
        • Public groups
        • Roles
        • Individual users
        • Territories
        • subordinates
     3. Access type
        Admins enable either read-only or read/write access, depending on the work required on the records. They grant the necessary access, whether read-only for the general public or edit access.
   • Permissions in sharing rules
     Here are four permissions for sharing rules.
     Private: Only the record owner can access it.
     Public read: Other members in the group can only read the data
     Public read/ write: Other members can read and edit the data
     Public read/write and transfer: All users can view, edit, transfer, and report on all records. Only available for cases or leads. Means we can transfer permissions. A transfer changes ownership, allowing further permissions to be granted to that user.
   • Limitations of Sharing Rules in Salesforce
     Let’s break down the limitations in sharing rules.
     • Regardless of whether a user is active, access is provided through sharing rules.
     • Whenever a user or role is changed, sharing rules are reevaluated.
     • Sharing rules grant users access to any records linked to the specific record, compromising data integrity. 

Record Type in Salesforce

Record types let you offer different business processes, picklist values, and page layouts to different users. The record type defines an interface that aligns with the business process.

Record types are :

1. Page layouts
2. Validation rule

1. Page Layouts:

Page layouts control the layout and organisation of buttons, fields, s-controls, Visualforce, custom links, and related lists on object record pages. They also help determine which fields are visible, read-only, and required. Use page layouts to customise the content of record pages for your users. It determines the field types and their organisation for a specific user on a page.

• A page layout controls the position and organisation of the fields and related lists visible to users when viewing a record.
• They help control the visibility of fields on a record.
• We can set fields as read-only or hidden, and control which fields require a value and which don’t.
• Page layout should never be used to restrict access to sensitive data that a user shouldn’t view or edit. Although we can hide a field from a page layout, users can still access it there and through other parts of the app, such as reports or the API.

2. Validation Rules in Salesforce

Validation rules help you to improve data quality by preventing users from entering incorrect data. We can write one or more validation rules, each consisting of an error and a corresponding error message.

Validation rules verify that the data a user enters into a record meets the standards you specify before the user can save it.

A validation rule can contain a formula or expression that evaluates the data in one or more fields and returns a value of “True” or “False”. Validation rules also include an error message to display to the user when the rule returns “True” because of an invalid value.

• Determines whether a value must be accepted or not with respect to a field.
• Validation rules verify that the data a user enters in your app meets the standards you specify. If it doesn’t, the validation rule prevents the record from being saved, and the user sees an error message defined either next to the problematic field or at the top of the edit page.

Audit Trail in Salesforce

Protecting the data is a common requirement for Salesforce and its users. An audit trail helps Salesforce users trace modifications to their data. It logs all modifications to personalisation, sharing, security, and data management.

Let’s discover how the audit trail works in Salesforce.

• Malware and Phishing: If you notice anything suspicious related to the Salesforce implementation, it may indicate a malware or phishing attack.
• Security Health Check: Admins can apply a health check to detect and address potential security weaknesses from a single page. You can use the summary score to show the organisation's measures against a security benchmark.
• Auditing: Auditing provides information on system utilization, which can be essential for addressing real security problems.
• Salesforce Shield: It is a set of security tools that admins use to build the next level of transparency, compliance, trust, etc., into business-critical applications.

Tracking Setup changes through the Salesforce audit trail:

In Salesforce, the setup audit trail tracks the modern setup modifications you create in your Salesforce portal.

Let’s explore tracking setup changes further.

1. Previous Custom Object Events: You can set up an audit trail to trace all actions associated with the creation and modification of custom objects of your enterprise.
2. Handle user events: Audit Trail tracks all user events, such as account creation and deletion.
3. Application events: Audit Trail traces all events related to configuring the applications associated with your enterprise.

In Salesforce, the audit trail helps users trace modifications in their organisation. It will report all the events related to users and their applications.

Translation Bench in Salesforce Security

The Translation Workbench lets you specify languages you want to translate, assign translators to languages, create translations for customisations you’ve made to your Salesforce organisation, and override labels and translations from managed packages. 

Everything, including custom picklist values for custom fields, can be translated so your global users can use Salesforce in their language.

• We can convert the app to any other language.
• The app can be developed in one language and translated into another.

Frequently Asked Questions

1. What is the use of sharing rules in Salesforce?

Ans: Users can share records based on criteria using sharing rules. Since sharing rules may only expand access rather than restrict it, they are generated for objects whose organisation-wide defaults (OWD) are set to public read-only or private.

2. What are the sharing rules and OWD in Salesforce?

Ans: OWD imposes limitations, and other systems permit access. Salesforce offers a feature called Sharing Rules to grant this access. Records can be shared with users who don't have access to them using sharing rules. Users in open groups, roles, or territories are granted access based on sharing rules.

3. What is the difference between sharing rules and permission sets?

Ans: It's similar to expanding a profile to create a permission set. A permission set with create/read/write on an object will only allow the user to create and manage their own records, not records held by other users, if the organisation-wide sharing rules for that object are set to private.

4. How many sharing rules per object?

Ans: If an object has criteria-based or guest user sharing rules available, you can define up to 50 of those for each object, for a total of 300 sharing rules. These forms of sharing regulations can be established. Other items in your org might be subject to sharing rules.

5. How do I deploy sharing rules in Salesforce?

Ans: Using the Change Set or Metadata API, you can test a sharing rule in a sandbox or development environment before deploying it to your production environment in Salesforce. Verify that it has been appropriately deployed and is operating as expected in the production environment before concluding.

6. Which object cannot have sharing rules in Salesforce?

Ans: It is not possible to include sharing rules in a package or utilise them to support sharing logic for programmes downloaded through the Force.com AppExchange. Record ownership or other factors may be used to determine sharing restrictions. Creating criteria-based sharing rules is not possible in Apex. Apex cannot be used to evaluate criteria-based sharing.

7. Who can create sharing rules in Salesforce?

Ans: You can establish sharing rules that allow guests who are not authenticated to view records based on the record owner or other criteria. For the User object, you can additionally establish sharing policies based on group membership.

8. What is the difference between sharing rules and manual sharing in Salesforce?

Ans: Records can be shared with users who don't have access to them using sharing rules. Users in open groups, roles, or territories are granted access based on sharing rules. They give people who are now unable to view records due to OWD settings increased access. A record may be shared in several ways.

9. Do sharing rules override the profile?

Ans: Profiles supersede the privileges offered by Sharing Rules at the user level. For instance, you cannot allow Write permission in Sharing Rules if Profiles do not grant Edit.

Conclusion

It’s a wrap! We hope that this Salesforce security tutorial helped you understand how Salesforce protects sensitive data. Also, you should have gained a thorough understanding of how Salesforce ensures data integrity and compliance, and delivers a delightful customer experience.

If you are interested in learning more about Salesforce security, you can take a course in MindMajix. By the end of the article, you will gain a comprehensive understanding of Salesforce’s robust security features and how it ensures data security on a large scale.