SalesforceTen.com

5-10 Mins read

Types of Security in Salesforce

Salesforce provides several types of security to protect data and control access:

1. Organization-Level Security
2. Object-Level Security
3. Field-Level Security
4. Record-Level Security
5. Data Encryption
6. Auditing and Monitoring

1. Organization-Level Security

• Purpose: Controls access to the Salesforce environment.
• Key Features:
• Login Access:
  • IP Restrictions: Restrict logins to specific IP ranges for added security.
  • Example: Only allow logins from the company’s office network.
  • Login Hours: Define allowed login times for users.
  • Example: Employees can log in only between 9 AM and 6 PM.
• Authentication:
  • Multi-Factor Authentication (MFA): Adds an extra layer of security by requiring a second authentication factor.
  • Example: A user must enter a code sent to their phone after entering their password.
  • Single Sign-On (SSO): Allows users to access Salesforce with their existing credentials from another system.
  • Example: Employees log in using their corporate email credentials.
• Password Policies: Set rules for password complexity, expiration, and history.
  • Example: Passwords must be at least 8 characters long and include a number.

2. Object-Level Security

• Purpose: Determines which objects a user can view, create, edit, or delete.
• Key Features:
• Permission Sets: Provide additional object-level permissions to specific users without altering their profile.
  • Example: A sales rep can be given access to the “Opportunity” object without changing their profile.
• Permission Set Groups: Combine multiple permission sets into a single group for easier management.
  • Example: A “Sales Manager” permission set group includes permissions for Accounts, Opportunities, and Leads.
• Standard vs. Custom Objects: Apply permissions to both Salesforce’s built-in objects (e.g., Accounts, Contacts) and custom objects.
  • Example: A custom object like “Employee Records” can be restricted to HR only.

3. Field-Level Security

• Purpose: Controls which fields on an object users can view or edit.
• Key Features:
• Set field visibility through Field-Level Security settings in profiles and permission sets.
  • Example: A sales rep can see a customer’s name and address but not their Social Security Number.
• Fields can be:
  • Visible: Users can view and edit.
  • Example: A customer’s phone number is visible to the sales team.
  • Read-Only: Users can view but not edit.
  • Example: A customer’s credit score is visible but cannot be modified by sales reps.
  • Hidden: Users cannot see or edit.
  • Example: A customer’s bank account number is hidden from all users except Finance.
• Use Case: Hide sensitive fields like Social Security Numbers or salary details from certain user groups.

4. Record-Level Security

• Purpose: Controls access to individual records within an object.
• Key Features:
• Organization-Wide Defaults (OWD): Sets the baseline level of access (e.g., public, private, or read-only) to records for each object.
  • Example: All “Account” records are set to private, so only the owner can view them.
• Role Hierarchies: Grant access to records owned by users lower in the hierarchy.
  • Example: A sales manager can view all records owned by their team members.
• Sharing Rules: Extend access to records based on criteria (e.g., all users in a certain department).
  • Example: All users in the “Sales” department can view all “Opportunity” records.
• Manual Sharing: Allow users to share individual records with other users or groups.
  • Example: A sales rep shares a customer record with a colleague for collaboration.
• Territory Management: Manage record access based on geographic or business territories.
  • Example: Sales reps in the “North Region” can only access accounts in their territory.

5. Data Encryption

• Purpose: Protect sensitive data at rest and in transit.
• Key Features:
• Shield Platform Encryption: Encrypts data fields and attachments for enhanced security.
  • Example: A customer’s credit card number is encrypted and cannot be read without the decryption key.
• Transport Layer Security (TLS): Encrypts data as it is transmitted between Salesforce and users.
  • Example: Data sent from Salesforce to a user’s browser is encrypted to prevent interception.

6. Auditing and Monitoring

• Purpose: Track and monitor changes to data and configuration.
• Key Features:
• Field History Tracking: Track changes to specific fields.
  • Example: An admin can see who changed a customer’s billing address and when.
• Audit Trail: Logs changes to organization-level settings.
  • Example: An admin can track changes to login IP restrictions.
• Event Monitoring: Tracks user activity and performance.
  • Example: An admin can monitor which users accessed sensitive records.
• Login History: Monitors login attempts and failures.
  • Example: An admin can see if a user failed to log in multiple times, indicating a potential security breach.

Security Best Practices

• Use Profiles and Permission Sets: Enforce least privilege by granting only necessary permissions.
• Example: A sales rep should not have access to HR records.
• Implement Multi-Factor Authentication (MFA): Add an extra layer of security for all users.
• Example: Require a code sent to the user’s phone after entering their password.
• Regularly Audit Field-Level Security and Sharing Settings: Ensure only authorized users can access sensitive data.
• Example: Review who can view customer credit card numbers.
• Use Shield Platform Encryption: Encrypt sensitive data to protect it from unauthorized access.
• Example: Encrypt employee salary details.
• Train Users on Security Awareness: Educate users on proper data handling and security practices.
• Example: Train employees to recognize phishing emails.

Summary Table for Security Concepts in Salesforce

Real-Time Scenario for Salesforce Security

Imagine you work for a company that sells expensive equipment. The company has different departments like Sales, Finance, and HR. Each department needs access to different types of data in Salesforce. Here’s how Salesforce security works in this real-time scenario:

1. Organization-Level Security

• Scenario: Only employees from your office location should be able to log in to Salesforce, and they should only be able to access Salesforce during business hours.
• Security Action:
• IP Restriction: Only allow users to log in from the company’s network.
• Login Hours: Employees can log in only between 9 AM and 6 PM.
• Example: An employee tries to log in from home after 6 PM—Salesforce denies access, ensuring no unauthorized access.

2. Object-Level Security

• Scenario: A sales rep should have access to customer accounts, but HR should not.
• Security Action:
• The sales rep’s profile allows them to view and edit the “Account” object, but HR staff cannot even see “Account” records.
• Example: A sales rep updates an account record, but when HR tries to access it, they get an error that they don’t have permission.

3. Field-Level Security

• Scenario: Salespeople need to see customer contact details but should not view sensitive financial data.
• Security Action:
• Hide sensitive fields like credit card details from sales reps, making it visible only to the Finance department.
• Example: A sales rep can view the customer’s name, address, and phone number, but the field for credit card number is hidden.

4. Record-Level Security

• Scenario: A manager needs to see all customer accounts, while a sales rep should only access their own accounts.
• Security Action:
• Role Hierarchy: Managers have access to records of their team’s accounts, but reps can only see their own.
• Sharing Rules: The sales manager can see all customer records in the team, but a rep can only view their assigned customers.
• Example: The sales rep opens a record for a customer they manage, but when the manager opens the same record, they can see a broader view of the customer’s interactions.

5. Data Encryption

• Scenario: The company handles sensitive customer data, such as credit card numbers and personal identification details.
• Security Action:
• Salesforce Shield Encryption encrypts sensitive data at rest.
• Example: If someone tries to access encrypted customer data, they will only see gibberish unless they have the proper decryption key.

6. Auditing and Monitoring

• Scenario: The company needs to track who accessed and changed critical records.
• Security Action:
• Login History: Tracks who logged in, when, and from which device.
• Field History Tracking: Keeps a record of changes made to sensitive fields.
• Example: A user changes an account’s billing address, and an admin can later check the audit logs to see who made the change.

7. Compliance Features

• Scenario: The company needs to follow GDPR regulations, which require customer data to be protected and erased when requested.
• Security Action:
• Data Masking: Mask customer information during testing to ensure privacy.
• Retention Policies: Set data to be deleted after a certain time to comply with GDPR.
• Example: If a customer requests their personal data to be deleted, the system ensures that their information is erased from the database.

Creating a diagram for Salesforce security concepts can help visualize the layers and relationships between different security features. Below is a text-based diagram that you can easily convert into a visual format using tools like Lucidchart, Draw.io, or PowerPoint.

Salesforce Security Layers Diagram

1. Organization-Level Security

+-----------------------------+
| Organization-Level Security |
+-----------------------------+
| - Login Access              |
|   - IP Restrictions         |
|   - Login Hours             |
| - Authentication            |
|   - Multi-Factor Auth (MFA) |
|   - Single Sign-On (SSO)    |
| - Password Policies         |
+-----------------------------+

2. Object-Level Security

+-----------------------------+
| Object-Level Security       |
+-----------------------------+
| - Permission Sets           |
| - Permission Set Groups     |
| - Standard vs. Custom Objs  |
+-----------------------------+

3. Field-Level Security

+-----------------------------+
| Field-Level Security        |
+-----------------------------+
| - Visible Fields            |
| - Read-Only Fields          |
| - Hidden Fields             |
+-----------------------------+

4. Record-Level Security

+-----------------------------+
| Record-Level Security       |
+-----------------------------+
| - Organization-Wide Defaults|
| - Role Hierarchies          |
| - Sharing Rules             |
| - Manual Sharing            |
| - Territory Management      |
+-----------------------------+

5. Data Encryption

+-----------------------------+
| Data Encryption             |
+-----------------------------+
| - Shield Platform Encryption|
| - Transport Layer Security  |
+-----------------------------+

6. Auditing and Monitoring

+-----------------------------+
| Auditing and Monitoring     |
+-----------------------------+
| - Field History Tracking    |
| - Audit Trail               |
| - Event Monitoring          |
| - Login History             |
+-----------------------------+

7. Compliance Features

+-----------------------------+
| Compliance Features         |
+-----------------------------+
| - Data Masking              |
| - Retention Policies        |
+-----------------------------+

Flow of Salesforce Security Layers

+-----------------------------+
| Organization-Level Security |
+-----------------------------+
            |
            v
+-----------------------------+
| Object-Level Security       |
+-----------------------------+
            |
            v
+-----------------------------+
| Field-Level Security        |
+-----------------------------+
            |
            v
+-----------------------------+
| Record-Level Security       |
+-----------------------------+
            |
            v
+-----------------------------+
| Data Encryption             |
+-----------------------------+
            |
            v
+-----------------------------+
| Auditing and Monitoring     |
+-----------------------------+
            |
            v
+-----------------------------+
| Compliance Features         |
+-----------------------------+

Example Use Cases

1. Organization-Level Security

+-----------------------------+
| IP Restrictions             |
+-----------------------------+
| Only allow logins from the  |
| company’s office network.   |
+-----------------------------+

2. Object-Level Security

+-----------------------------+
| Permission Sets             |
+-----------------------------+
| Sales reps can edit Accounts|
| but not Employee Records.   |
+-----------------------------+

3. Field-Level Security

+-----------------------------+
| Hidden Fields               |
+-----------------------------+
| Hide credit card numbers    |
| from sales reps.            |
+-----------------------------+

4. Record-Level Security

+-----------------------------+
| Role Hierarchies            |
+-----------------------------+
| Managers can see all records|
| owned by their team.        |
+-----------------------------+

5. Data Encryption

+-----------------------------+
| Shield Platform Encryption  |
+-----------------------------+
| Encrypt credit card numbers |
| to protect sensitive data.  |
+-----------------------------+

6. Auditing and Monitoring

+-----------------------------+
| Field History Tracking      |
+-----------------------------+
| Track changes to billing    |
| addresses in customer data. |
+-----------------------------+

7. Compliance Features

+-----------------------------+
| Data Masking                |
+-----------------------------+
| Mask customer data during   |
| testing to ensure privacy.  |
+-----------------------------+

How to Visualize This Diagram

1. Use a Tool: Open a diagramming tool like Lucidchart, Draw.io, or PowerPoint.
2. Create Boxes: Add boxes for each security layer (e.g., Organization-Level Security, Object-Level Security).
3. Add Arrows: Use arrows to show the flow between layers (e.g., Organization-Level → Object-Level → Field-Level).
4. Add Examples: Include example use cases in smaller boxes below each layer.
5. Color Code: Use different colors for each layer to make the diagram visually appealing.

Final Diagram Structure

+-----------------------------+       +-----------------------------+       +-----------------------------+
| Organization-Level Security | ----> | Object-Level Security       | ----> | Field-Level Security        |
+-----------------------------+       +-----------------------------+       +-----------------------------+
            |                                   |                                   |
            v                                   v                                   v
+-----------------------------+       +-----------------------------+       +-----------------------------+
| Example: IP Restrictions    |       | Example: Permission Sets    |       | Example: Hidden Fields      |
+-----------------------------+       +-----------------------------+       +-----------------------------+

This text-based diagram can be easily converted into a visual format. Let me know if you need further assistance or a more detailed visual representation!

Conclusion

This real-time scenario shows how different Salesforce security features come together to protect data and control access, ensuring that employees can only see and do what’s necessary for their job. Whether it’s securing sensitive data, controlling who sees what, or tracking user actions, Salesforce provides a secure environment for handling business operations.