Field Level Security in Salesforce

Field Level Security in Salesforce

On September 24, 2025, Posted by , In Salesforce, With Comments Off on Field Level Security in Salesforce

Table Of Contents

In this blog, we’ll dive deep into the intricacies of field-level security in Salesforce and explore other important sharing options such as Public Groups, Queues, and Teams. Understanding these concepts is crucial for effective data management and maintaining confidentiality within your Salesforce org. By mastering these tools, you’ll be better equipped to manage user access and keep sensitive data secure.

What is Field-Level Security?

Field-level security in Salesforce plays a critical role in controlling the visibility of fields to users. While your Salesforce org contains vast amounts of data, not all fields should be accessible to all users, especially sensitive information like salary details or social security numbers.

Field-level security determines whether a user can view, edit, or delete the value for a specific field on an object. This security setting goes beyond the visibility of fields on page layouts, affecting reports, list views, related lists, API access, and search results as well.

Key Considerations for Field-Level Security

1. Editions Supporting Field-Level Security

Explanation:
Field-level security is available across a range of Salesforce editions. This includes Professional, Enterprise, Performance, Unlimited, and Developer editions. These editions offer varying levels of functionality, but field-level security ensures data protection is consistent across all supported versions.

Significance:

  • Ensures that organizations of all sizes and industries, regardless of their edition, can secure sensitive data fields.
  • Even in the lower-tier Professional Edition, field-level security is accessible, making it a versatile feature.

Example:
A small business using the Professional Edition can secure sensitive customer data (e.g., credit card information) while allowing broader data access to less-sensitive fields like customer names or addresses.

2. Overrides Page Layout Settings

Explanation:
Field-level security settings take precedence over page layout settings. Even if a field is added to a page layout, it will not be visible to users unless the field-level security allows it.

Significance:

  • Acts as a higher layer of security to ensure restricted fields cannot be accidentally exposed through layouts.
  • Guarantees data protection by applying the most restrictive rules.

Example:
If a field for “Salary Details” is included on a page layout but the field-level security does not permit visibility for a user’s profile, the user will not see the field, even on the page layout.

3. Configuration for Multiple Profiles via Field Accessibility

Explanation:
Salesforce allows administrators to configure field-level security for multiple profiles simultaneously through the Field Accessibility section in Setup. This feature provides a centralized view of field permissions for all profiles and record types.

Steps to Configure:

  1. Go to Setup → Object Manager → Select the Object.
  2. Click on Field Accessibility.
  3. View and update the visibility and editability of fields for all profiles in one place.

Significance:

  • Saves time by enabling batch updates for profiles.
  • Simplifies field security audits by presenting all settings in a single view.

Example:
An administrator can review and adjust field permissions for a custom field, such as “SSN,” across all profiles without individually editing each profile.

4. Extendable to Specific Users via Permission Sets

Explanation:
While profiles define baseline permissions, permission sets allow administrators to grant additional field-level access to specific users without altering their assigned profile.

Significance:

  • Provides flexibility in assigning permissions to individual users with unique requirements.
  • Enables administrators to avoid creating additional profiles for edge cases, reducing complexity.

Use Case:
An organization wants a single sales rep to access the “Discount Percentage” field for special client negotiations. Instead of altering the profile for all sales reps, the admin can create a permission set granting access to this field and assign it to the specific user.

Example Steps:

  1. Create a Permission Set.
  2. Assign the required field permissions (Visible or Read/Write).
  3. Assign the permission set to the individual user.

Why These Considerations Matter

Field-level security is an essential tool for ensuring that users access only the data necessary for their roles. These considerations highlight how Salesforce balances functionality and security, giving organizations flexibility and control over sensitive information.

Security Options for Profiles

In Salesforce, you can configure field-level security settings for different profiles. These options are:

  • Visible: This setting makes the field visible to users of the corresponding profile.
  • Read Only: If selected, this option restricts users from editing the field value. If unchecked, the field remains editable for users with the profile.
  • No Access: If neither option is selected, users cannot view or edit the field.

Factors Determining Field-Level Access

Several factors influence users’ access to a field, including:

1. Field-Level Security

Example:
In Salesforce, Field-Level Security can be configured via the Setup menu or programmatically using Apex. Here’s an example of how to check and set field-level security for a specific field via Apex.

Apex Example:

// Example to check if a field is visible for a user
SObjectField field = Account.Employee_Salary__c; // custom field on Account object
Schema.DescribeFieldResult fieldResult = field.getDescribe();

// Check if the field is visible for the current user's profile
Boolean isFieldVisible = fieldResult.isAccessible();
if (isFieldVisible) {
    System.debug('Field is visible to the current user');
} else {
    System.debug('Field is NOT visible to the current user');
}

// To change field-level security for a profile, you must do it via Setup manually or through metadata API

Explanation:

  • In this code, we use Schema.DescribeFieldResult to check if the “Employee Salary” field is accessible to the current user. The isAccessible() method helps determine the visibility of a field based on the current user’s profile.
  • Use Apex to check whether a field is accessible based on the user’s profile.

2. Page Layouts

Example:
While page layouts can display fields, field-level security ensures that only users with the appropriate permissions can view or edit those fields.

Scenario:

  • A field named “Salary” is added to the page layout of the Employee object for the Manager profile. However, if the Field-Level Security for this field is set to Read-Only or Hidden for the Manager profile, the field will not be visible or editable on the page layout.

Explanation:

  • In Salesforce, you can add/remove fields from a page layout via Setup, but the field will only be visible if field-level security allows access to it. If field-level security hides or restricts the field, it will not appear on the page layout, even if the layout includes it.
  • Permissions like “View All” and “Modify All” can bypass field-level security

3. Permissions

Example:
Permissions like “View All” and “Modify All” allow users to bypass field-level security and access fields and records.

Apex Example:
You can check a user’s permissions in Apex by using the FeatureManagement class. Here’s an example of checking if the current user has “View All” permissions for the Account object.

// Check if current user has "View All" permission on Account object
Boolean hasViewAllPermission = Schema.sObjectType.Account.isAccessible();
if (hasViewAllPermission) {
    System.debug('User can access Account records');
} else {
    System.debug('User cannot access Account records');
}

Explanation:

  • The isAccessible() method checks whether the user has access to the Account object based on their permissions. If the user has “View All” or “Modify All” permission for the object, they can bypass field-level security and access all fields, regardless of the field’s security settings.

4. Universally Required Fields

Example:
When a custom field is marked as universally required, it becomes mandatory for all users to fill it out, and it bypasses field-level security restrictions. This field must be visible and editable for all users.

Scenario:

  • A custom field called “Emergency Contact Name” is set as universally required for all profiles.

Explanation:

  • Even if a profile has field-level security set to Read-Only for this field, the universally required setting forces the field to be visible and editable.

Steps to make a field universally required:

  1. Go to Setup → Object Manager → Select Object (e.g., Contact).
  2. Find the custom field (e.g., Emergency Contact Name).
  3. Set it as Required.
  4. Once set as universally required, this field will be visible and editable for all users, bypassing field-level security.

5. Lookup and System Fields

Example:
When using Lookup Fields, you can restrict access to the Record Name using the “Require Permission” setting.

Scenario:

  • You have a lookup field on the Case object, where users can link a Contact record. If the user does not have access to the Contact object, the Record Name in the lookup field will not be visible to them.

Apex Example:

// Check if the current user has permission to view a related object in a lookup field
SObjectType contactType = Schema.getGlobalDescribe().get('Contact');
Schema.DescribeSObjectResult contactDescribe = contactType.getDescribe();
Boolean canViewContact = contactDescribe.isAccessible();

if (canViewContact) {
    System.debug('User has permission to view the Contact record in the lookup');
} else {
    System.debug('User cannot view the Contact record in the lookup');
}

Explanation:

  • The isAccessible() method checks whether the current user has permission to access the Contact object, which affects their ability to view the Record Name in the Case lookup field. If the user does not have permission, they won’t be able to see the related Contact record name.
  • “Require Permission” ensures that users cannot view related record names in lookup fields unless they have the required access.

Use Case Scenario

Scenario:
A company needs to restrict certain profiles from viewing payroll and SSN information on a custom Employee object. These fields should be hidden for non-admin users, such as regular employees, while they should be visible for HR managers and admin profiles.

This is a typical example of how Field-Level Security is used to control access to sensitive data in Salesforce, ensuring that users can only see the fields they are authorized to view.

Step-by-Step Breakdown

  1. Field-Level Security Configuration
    • The payroll and SSN fields need to be restricted for most users (e.g., Employee Profile).
    • However, these fields must remain visible for users with certain profiles, such as HR Manager and Admin.
  2. How to Restrict Access via Field-Level Security:
    • Field-level security must be configured to hide or restrict access to sensitive fields like payroll and SSN for specific profiles.
  3. Page Layouts:
    • Although you may configure the page layout to include these fields for users like HR managers, Field-Level Security can still override the page layout and restrict access.

Example 1: Restricting Access to Sensitive Fields for Specific Profiles

Step 1: Set Field-Level Security for Profiles

  1. Navigate to Setup → Object Manager → Employee Object → Fields & Relationships.
  2. Find the payroll and SSN fields.
  3. Click on Set Field-Level Security for each field.
  4. Uncheck Visible for the Employee Profile, ensuring the field is hidden for that profile. Leave it checked for HR Manager and Admin Profiles.

This will ensure that regular users with the Employee Profile cannot view these fields, while HR managers and admins retain access to them.

Step 2: Page Layout Configuration

Even though Field-Level Security restricts access, you can still configure the page layout to include the payroll and SSN fields for HR managers. However, if the field is not visible due to field-level security, it won’t appear on the page layout for those users who do not have access.

Example 2: Use Apex to Check Field-Level Security

You can also use Apex to check and enforce field-level security programmatically, especially when the security settings need to be dynamically applied based on business logic.

Apex Example: Checking Field-Level Security

Here’s how to programmatically check whether a user has access to a field (like SSN or payroll) based on their profile:

// Example to check if a field is visible for a specific profile
SObjectField payrollField = Employee__c.Payroll__c;  // Custom field on Employee object
Schema.DescribeFieldResult payrollFieldResult = payrollField.getDescribe();

// Check if the field is visible to the current user's profile
Boolean isPayrollVisible = payrollFieldResult.isAccessible();
if (isPayrollVisible) {
    System.debug('User has access to the Payroll field');
} else {
    System.debug('User does NOT have access to the Payroll field');
}

// Similarly, check for SSN field
SObjectField ssnField = Employee__c.SSN__c;  // Custom field on Employee object
Schema.DescribeFieldResult ssnFieldResult = ssnField.getDescribe();

Boolean isSSNVisible = ssnFieldResult.isAccessible();
if (isSSNVisible) {
    System.debug('User has access to the SSN field');
} else {
    System.debug('User does NOT have access to the SSN field');
}

Explanation:

  • getDescribe() is used to get metadata for the field. The isAccessible() method checks if the field is visible to the user based on their profile settings and field-level security.
  • The code checks the visibility of the payroll and SSN fields and prints whether the current user has access to them.

Example 3: Use Case Scenario for Dynamic Field Access Control

Scenario:

An organization wants to restrict the visibility of the “Salary” field on the Employee object, but this should only be restricted for users who are not in the HR department.

Step 1: Create a Permission Set

  1. Go to Setup → Permission Sets → Create New Permission Set.
  2. Set the Salary field in the Employee object to Hidden by default for users who are not in the HR department.
  3. Assign this permission set to HR users to ensure they can see the Salary field.

Step 2: Custom Logic to Enforce Field Visibility

If you want to enforce this rule programmatically in Apex based on certain conditions (like user’s role), you can add custom logic that checks if the user is part of the HR team.

// Check if the user is part of the HR team
User currentUser = [SELECT Id, Profile.Name FROM User WHERE Id = :UserInfo.getUserId() LIMIT 1];
String userProfileName = currentUser.Profile.Name;

if (userProfileName == 'HR Manager') {
    // Allow access to Salary field
    System.debug('User has access to the Salary field');
} else {
    // Deny access to Salary field
    System.debug('User does NOT have access to the Salary field');
}

Explanation:

  • The above code checks if the current user’s profile is HR Manager.
  • Based on the user profile, you can decide if the user should have access to sensitive fields like Salary. This complements the field-level security settings and provides an additional layer of programmatic control.

Example 4: Use Case for Lookup Fields and Record Types

Scenario:

You have a Case object with a Contact Lookup field. However, not all users should see the Contact Name in the lookup field, especially those without the right permissions to view the Contact object.

Step 1: Configure Field-Level Security for Lookup Field

  1. Go to Object Manager → Case → Fields & Relationships.
  2. Set the Contact Lookup field’s field-level security appropriately to hide it for users who shouldn’t see it.

Step 2: Enforce Record Visibility in Apex

You can programmatically ensure that only users with proper permissions can see the related Contact Name in the lookup field.

// Check if user has permission to view related Contact records
SObjectType contactType = Schema.getGlobalDescribe().get('Contact');
Schema.DescribeSObjectResult contactDescribe = contactType.getDescribe();
Boolean canViewContact = contactDescribe.isAccessible();

if (canViewContact) {
    System.debug('User has permission to view the Contact record');
} else {
    System.debug('User cannot view the Contact record');
}

Explanation:

  • The isAccessible() method checks if the current user has permission to view the Contact object. If the user doesn’t have permission, the related Contact Name in the Case lookup will be hidden.

Record Sharing Options in Salesforce

Besides field-level security, Salesforce offers various options to share records among users. This includes the use of Public Groups, Queues, and Account, Opportunity, and Case Teams. These features provide flexible sharing settings to enhance collaboration while maintaining control over who can access what data.

Groups

A group in Salesforce is a set of users, roles, territories, or other groups, facilitating collaborative work and record sharing.

Types of Groups

  • Public Groups: Created by administrators or delegated administrators and accessible to any user in the Salesforce organization.
    • Example: A CSR group for sharing information about CSR activities.
  • Personal Groups: Created by individual users for personal use and exclusive to the creator.
    • Example: Sharing specific records with a select group of users.

Uses of Public Groups

  • Setting up sharing access via sharing rules.
  • Manually sharing records.
  • Sharing Salesforce CRM Content libraries.
  • Assigning actions in Salesforce Knowledge.
  • Synchronizing contacts.

Key Considerations

  • Create groups for users with similar access needs (e.g., Direct Sales Reps).
  • Limit nesting of public groups to avoid unnecessary complexity.
  • Use Grant Access Using Hierarchies to share with group members’ hierarchy.

Queues

Queues in Salesforce help prioritize, distribute, and assign records to groups, thus enhancing collaborative efforts.

Queue Members

Queues can include:

  • Individual users
  • Roles or Roles and Subordinates
  • Public Groups

Record Assignment

  • Assignment Rules: Automatically add records to a queue based on predefined criteria.
  • Manual Assignment: Update record ownership to a Queue, such as transferring ownership of a Case record.

Account, Opportunity, & Case Teams

These teams allow collaboration on Accounts, Opportunities, and Cases without the need for users to own the records.

  1. Account Teams: A group of users working on an account, granting access to related records.
    • Access levels: Read, Read/Write, or Private.
  2. Opportunity Teams: Users collaborate on Opportunities and extend record-level sharing.
    • Users can set up default teams to be automatically added to opportunities.
  3. Case Teams: Groups of users working together on cases with read or read/write access.
    • Allow adding contacts as customer portal users.

Use Case Scenario

Challenge: A sales rep works with a predefined team for each account created, including a Sales Manager, Customer Success Manager, and Finance contact.

Solution: Utilize Default Account Teams to automate the addition of team members to newly created accounts.

Reason: Users can set up default account teams in their personal settings, which are automatically added to accounts upon creation or ownership transfer.

Conclusion

Navigating the diverse landscape of Salesforce’s security and sharing settings is essential for optimizing both data protection and collaborative efficiency. From the detailed exploration of field-level security to the in-depth analysis of various sharing options like Public Groups, Queues, and Account, Opportunity, & Case Teams, this guide has covered the pivotal aspects of managing data access in Salesforce. By understanding and applying these features, you can ensure that the right people have the right access to the right data.

← →
Comments are closed.