Salesforce is one of the most widely used CRM platforms for managing customer, sales, service, healthcare, financial, and business data. Because CRM systems often contain sensitive information, Salesforce data security should be treated as a continuous process rather than a one-time configuration.
A strong Salesforce security model ensures that users can access the information they need to perform their jobs while preventing unauthorized access, modification, or deletion of data. This article explains practical Salesforce data security best practices that administrators and developers can apply in real-world projects.
1. Understand the Salesforce Security Model
Before implementing security, it is important to understand how Salesforce controls access.
Salesforce security can broadly be considered at four levels:
- Organization level
- Object level
- Field level
- Record level
For example, an employee may be allowed to access the Salesforce org but may not have permission to delete Accounts. Another user may be able to view an Account but not see sensitive fields such as financial information.
A good security implementation uses multiple layers instead of relying on only one security feature.
2. Follow the Principle of Least Privilege
The principle of least privilege means users should receive only the permissions required for their job.
For example, a Sales Representative may need to:
- View Accounts
- Create Leads
- Update Opportunities
But they may not need permission to:
- Delete Accounts
- Modify security settings
- Export all organizational data
Giving unnecessary permissions increases security risks.
Instead of giving broad access through an administrator profile, create appropriate permission sets and permission set groups based on business responsibilities.
3. Use Profiles Carefully
Profiles provide baseline permissions for users.
A profile can control:
- Object permissions
- Field permissions
- System permissions
- App access
- Login hours
- IP restrictions
- Record types
- Page layouts
A common best practice is to avoid creating many unnecessary custom profiles. Keep profiles focused on baseline access and use Permission Sets to provide additional permissions.
For example:
Sales User Profile
+
Sales Manager Permission Set
+
Report Export Permission Set
This approach provides more flexibility than creating a separate profile for every combination of permissions.
4. Use Permission Sets and Permission Set Groups
Permission Sets are useful when a user needs additional access beyond their profile.
For example:
A Sales Executive may normally have access to Accounts and Opportunities. If that employee temporarily needs access to a special reporting application, you can assign a Permission Set rather than modifying the user's profile.
Permission Set Groups can combine multiple permission sets into a logical permission package.
For example:
Sales Manager PSG
↓
Opportunity Management
+
Advanced Reporting
+
Forecast Access
This makes permission management easier in large organizations.
5. Configure Object-Level Security
Object-level security controls whether users can:
- Create
- Read
- Edit
- Delete
records of a particular object.
For example, in a Hospital CRM:
Object
Receptionist
Doctor
Admin
Patient
Read/Create
Read/Edit
Full
Appointment
Create/Edit
Read/Edit
Full
Payment
Read
Read
Full
This prevents users from accessing objects that are outside their responsibilities.
6. Protect Sensitive Fields with Field-Level Security
Field-Level Security (FLS) determines whether a user can see or edit a particular field.
Suppose a Patient object contains:
- Patient Name
- Phone
- Medical History
- Insurance Number
A receptionist may need access to Name and Phone but may not need access to sensitive medical information.
Therefore:
Patient
├── Name → Visible
├── Phone → Visible
├── Email → Visible
└── Medical History → Restricted
FLS should be used whenever sensitive or confidential information exists.
7. Configure Organization-Wide Defaults
Organization-Wide Defaults (OWD) establish the baseline record-level access.
For example:
Account → Private
Opportunity → Private
Case → Private
If Opportunity OWD is Private, users don't automatically see every Opportunity.
Additional access can then be provided through:
- Role Hierarchy
- Sharing Rules
- Teams
- Manual Sharing
- Apex Managed Sharing
A good approach is to start with restrictive OWD settings and open access only where the business requires it.
8. Use Role Hierarchy Correctly
Role Hierarchy generally allows users higher in the hierarchy to access records owned by users below them, depending on object and sharing settings.
For example:
Sales Director
↓
Regional Manager
↓
Sales Executive
A Sales Manager may need access to records owned by their team.
However, roles should not be created simply to provide every type of access. Use the appropriate security mechanism for the specific requirement.
9. Use Sharing Rules for Business-Based Access
Sharing Rules provide additional record access based on ownership or criteria.
Example:
All members of the West Region Sales Team should have access to Accounts where Region = West.
A criteria-based sharing rule can provide this access automatically.
This is especially useful when access depends on business conditions rather than the reporting structure.
10. Secure External Access
Salesforce environments may be accessed through:
- Web browsers
- Mobile applications
- APIs
- Integration applications
- Experience Cloud sites
External access should be carefully controlled.
Important considerations include:
- Strong authentication
- Multi-factor authentication
- Appropriate login policies
- Connected App security
- OAuth scopes
- Session settings
- API access controls
Never assume that an authenticated user should automatically have access to all Salesforce data.
11. Use Multi-Factor Authentication
MFA adds an additional layer of security beyond a username and password.
Even if someone's password is compromised, the attacker may still need the additional authentication factor.
Organizations should establish secure authentication practices and regularly review login activity.
Users should also avoid sharing passwords or storing credentials in insecure locations.
12. Secure APIs and Integrations
Modern Salesforce implementations commonly integrate with external applications.
Examples include:
Salesforce
↓
REST API
↓
External Application
or:
Salesforce
↓
Integration Platform
↓
ERP / Payment System
For integrations:
- Use appropriate authentication.
- Avoid hard-coded credentials.
- Use Named Credentials where appropriate.
- Grant only required OAuth scopes.
- Use dedicated integration users where appropriate.
- Monitor integration activity.
- Avoid exposing sensitive information unnecessarily.
Never place usernames, passwords, tokens, or secrets directly inside Apex code.
13. Avoid Hard-Coded Security Information
Apex code should not contain credentials or sensitive configuration values.
Avoid:
String password = 'MyPassword123';
Instead, use appropriate Salesforce security mechanisms such as:
- Named Credentials
- External Credentials
- Protected configuration
- Appropriate metadata/configuration mechanisms
This makes applications safer and easier to maintain.
14. Secure Apex Code
Apex developers must consider Salesforce security when writing code.
Important practices include:
- Use with sharing where appropriate.
- Enforce object permissions.
- Respect Field-Level Security.
- Validate user input.
- Avoid unnecessary data exposure.
- Use secure SOQL practices.
- Avoid exposing sensitive fields through APIs or Visualforce pages.
For example:
public with sharing class AccountController {
public static List<Account> getAccounts() {
return [
SELECT Id, Name
FROM Account
LIMIT 100
];
}
}
with sharing helps enforce record-level sharing rules for the execution context.
However, developers should understand that with sharing alone does not automatically enforce every layer of object and field security.
15. Protect Data in Reports and Dashboards
Reports and dashboards can expose large amounts of information.
Administrators should carefully control:
- Report folder access
- Dashboard folder access
- Export permissions
- Report sharing
- Dashboard running-user settings
A dashboard should not accidentally expose confidential information to users who cannot normally access the underlying data.
16. Monitor and Audit User Activity
Security is not complete after configuration.
Administrators should regularly review:
- Login History
- Setup Audit Trail
- Field History Tracking
- Permission assignments
- Sharing settings
- API activity
- Unexpected changes
- Inactive users
Salesforce auditing and monitoring features can help identify suspicious or unexpected behavior.
Author:
Komal Wavare
Related Links:
Resume Tips For Software Developers
Do visit our channel to know more: SevenMentor
Komal Wavare
Expert trainer and consultant at SevenMentor with years of industry experience. Passionate about sharing knowledge and empowering the next generation of tech leaders.