Salesforce Override Role Hierarchy in Salesforce

Role hierarchy in Salesforce is a powerful mechanism that defines the access and visibility of records within an organization. By default, role hierarchies allow users higher in the hierarchy to access records owned by users below them. While this feature ensures data transparency and accessibility for managers and team leads, there are scenarios where you may want to override this behavior to enforce stricter record-level access controls.

In this article, we will explore how role hierarchy works, why overriding it may be necessary, and the various methods to achieve this in Salesforce. This guide is tailored for intermediate to advanced developers, covering both declarative and programmatic approaches with detailed examples.

How Role Hierarchy Works?

Role hierarchies in Salesforce are part of the organization-wide defaults (OWD) and define record visibility based on a user’s role. For example:

• A manager can access records owned by their subordinates.
• A team lead can access records owned by their team members.

This default behavior simplifies data access but may not align with all business requirements, such as when sensitive data must be restricted even from higher roles.

Key Features:

• Record Access: Users higher in the role hierarchy inherit access to records owned by users lower in the hierarchy.
• Custom Object Support: Role hierarchies work for both standard and custom objects.
• Grant Access Using Hierarchies: This setting, enabled by default, determines whether records follow the hierarchy.

Why Override Role Hierarchy?

There are several scenarios where you might need to override role hierarchy:

1. Sensitive Data: You want to restrict access to specific records, such as salary information or medical records, even from higher-level users.
2. Cross-Team Collaboration: You need to grant access to users in different roles without exposing data to everyone higher in the hierarchy.
3. Regulatory Compliance: Certain industries require stricter data access controls to comply with legal regulations like GDPR or HIPAA.

Methods to Override Role Hierarchy

1. Disable "Grant Access Using Hierarchies"

Salesforce allows you to disable the "Grant Access Using Hierarchies" setting on custom objects. This ensures that the role hierarchy does not apply to the object, and record-level access must be explicitly granted using sharing rules, manual sharing, or Apex sharing.

How to Disable:

• Go to Setup > Object Manager.
• Select the custom object.
• Navigate to Object Settings and uncheck Grant Access Using Hierarchies.
• Save the changes.

Considerations:

• This option is available only for custom objects.
• Disabling this setting does not affect standard objects, where role hierarchy access cannot be overridden directly.

2. Override Using Sharing Rules

Sharing rules allow you to define specific conditions to grant access to records, overriding the default role hierarchy behavior.

Example: Suppose you have a custom object Confidential_Document__c with sensitive information. You want to grant access only to specific roles, irrespective of the role hierarchy.

1. Set OWD to Private:

• Go to Setup > Sharing Settings.
• Set the Organization-Wide Default (OWD) for Confidential_Document__c to Private.

2. Create a Sharing Rule:

• Navigate to Setup > Sharing Settings.
• Under the Confidential_Document__c sharing settings, click New Sharing Rule.

Define the rule:

• Criteria-Based Sharing: For example, share records where Confidential_Level__c = 'High'.
• Shared With: Specify the roles or public groups to share with.
• Access Level: Set to Read-Only or Read/Write.

3. Use Apex Sharing for Custom Logic

Apex sharing provides a programmatic way to grant or revoke access to records, allowing you to implement complex logic that overrides the default role hierarchy.

Example: Let’s assume you need to share records of Confidential_Document__c with specific users based on custom criteria, such as department or seniority level.

Apex Code Example:

How It Works:

• The Confidential_Document__Share object is used to define sharing settings for the custom object.
• ParentId: Specifies the record to be shared.
• UserOrGroupId: Specifies the user or group with whom the record is shared.
• RowCause: Specifies the reason for sharing (e.g., Manual or a custom reason).

Trigger Example:

You can invoke the above logic in a trigger:

4. Field-Level Security and Validation Rules

If your goal is to restrict access to specific fields rather than entire records, consider using Field-Level Security or Validation Rules. These features complement role hierarchy overrides by providing finer control.

Example: Hide Sensitive Fields

1. Go to Setup > Profiles or Permission Sets.
2. Adjust the field-level security for the profile to make specific fields Read-Only or Hidden.

Best Practices for Overriding Role Hierarchy

1. Plan Access Requirements:

• Clearly define which users or roles need access to specific records and fields.
• Use a combination of OWD, sharing rules, and manual sharing for optimal control.

2. Test in Sandbox:

• Always test your changes in a sandbox environment to ensure that access is restricted or granted as expected without affecting other functionalities.

3. Use Custom Metadata for Flexibility:

• Store access control rules in custom metadata to simplify updates and reduce hardcoding in Apex.

4. Audit Sharing Settings:

• Periodically review and audit sharing settings to ensure compliance with organizational policies.

Conclusion

Overriding role hierarchy in Salesforce is a crucial capability for organizations requiring strict control over record access. By disabling "Grant Access Using Hierarchies", leveraging sharing rules, and employing Apex sharing, you can enforce complex access controls tailored to your business needs.

Understanding these techniques and implementing them correctly ensures data security and compliance while maintaining flexibility in how records are shared within your Salesforce org. With the right combination of declarative and programmatic tools, you can customize Salesforce access controls to suit any scenario.