Tips for Scaling Salesforce Sharing Configuration for Large Data Volumes

Introduction

The Salesforce platform provides a robust and flexible sharing model to control user access to records and data. Proper configuration of the sharing model is crucial for securing data access as required in any organization. This comprehensive guide will review the key components of the Salesforce sharing architecture, provide real-world examples and use cases for implementation, and best practices.

Intended for administrators and architects with experience in Salesforce security and sharing models. Prerequisites include familiarity with sharing settings, data security, record access design, and the Salesforce Well-Architected framework.

🔑 Key Components of the Sharing Model

There are several pivotal components and tools that make up the Salesforce sharing model:

Profiles and Permission Sets

Profiles and permission sets allow administrators to control object and field-level access to data. For each object, permissions can be set to allow users to view, create, edit, and delete records. The “View All” and “Modify All” permissions bypass sharing rules and role hierarchy to provide organization-wide access.

Permission sets are preferable to profiles for managing permissions, as they allow administers to reuse smaller modular permission sets instead of creating a profile for every user or function.

Record Ownership and Queues

Every record in Salesforce must have an owner, which is either a user or a queue. Owners have full control over their own records. Queues allow teams of users to collectively own records and provide capabilities like assigning records to team members.

If a single user owns more than 10,000 records, best practice is to not include their user record in the role hierarchy, or if required, position them at the top of their own hierarchy branch.

Organization-Wide Defaults

Organization-wide sharing settings control the baseline level of access users have to records they do not own. For example, “Private” means users can only access records they own or are shared with them explicitly. Settings can be configured separately per object.

Organization-wide defaults can be changed over time if needed, but require extensive sharing rule recalculation which can impact performance.

Role Hierarchy

The role hierarchy enables automatic data sharing based on a user’s role. Users higher in the hierarchy gain the same access as users below them. Role hierarchy ensures managers always have access to the same data as their direct reports.

The role hierarchy should reflect the data access needs rather than the formal organizational chart. Overlays may need additional components like sharing rules or teams to provide proper access.

Best practice is keeping the role hierarchy under 10 levels. More than 25,000 roles or 100,000 external roles requires consulting Salesforce support.

Sharing Rules

Sharing rules are automatic exceptions to organization-wide defaults and role hierarchies to provide access to other users based on criteria. There are multiple types:

• Owner-based – Provide access based on record ownership
• Criteria-based – Provide access based on field values
• Guest user – Provide access to guest users

Limits per object are 300 total sharing rules, with 50 criteria-based and guest user rules.

Manual Sharing

Manual sharing allows record owners to selectively share with other users directly. This can address “one-off” situations where automated rules don’t meet a need.

Manual sharing does not remain if record ownership changes. Limits are based on object volume (5% of total records).

Teams

Teams allow sharing groups of users per record. Can have different access levels like read-only or read/write. Useful for collaborating on accounts, opportunities, and cases.

Only record owners, managers, and admins can add team members or increase their access level. Creating a team generates a team record and a share record.

Implicit Sharing

Implicit sharing automatically provides access to related records, even if organization-wide defaults are restrictive. For example, if users can access contacts, they automatically get access to the parent account as well.

Implicit sharing only applies to the parent account object and its contact, opportunity, and case child objects. It does not extend to custom child objects.

Apex Managed Sharing

Apex managed sharing allows programmatic sharing rules when requirements can’t be met through configuration alone. Can track sharing reasons and simplify maintenance of the shares.

Use caution when implementing, as it can quickly expose data to many users if not carefully designed. Analyze all use cases thoroughly.

Restriction Rules

Restriction rules prevent users from accessing records that meet certain criteria, even if other sharing components give them access. Useful for limiting exposure of sensitive data.

Limits are 2 per object for Enterprise/Developer editions, 5 per object for Performance/Unlimited editions. Applies to many common objects like accounts, contacts, and opportunities.

☞ Use Cases and Scenarios

Every Salesforce organization has unique requirements and challenges when configuring the optimal sharing model. Here are some common examples:

External Team Management

Companies may maintain teams in an external system and want to automatically synchronize team membership to Salesforce. For example, mapping fields from the external system to Salesforce owner, role, and territory fields.

Possible solutions:

• Write automation to sync teams nightly and update memberships
• Use territory management to define regions and model externally managed teams
• Employ ETL tool to migrate team data on a schedule into Salesforce

Project Collaboration

Teams that span multiple business units need to collaborate on projects across regions, accounts, and opportunities.

Possible solutions:

• Define project territories in addition to regional territories
• Create project teams under opportunities with members from various business units
• Have project managers provide cross-territory access via sharing rules

Partner Record Access

Sharing select records and fields with external partner users requires access, but partners should only see data relevant to them.

Possible solutions:

• Criteria-based sharing rules to expose records based on partner ID field or lookup
• Mark key fields as accessible in partner portal profiles
• Record owners manually share with Partner Community users as needed

Acquisition Divestiture

Significant business structural changes like acquisitions, mergers, and divestitures require major reshaping of the sharing model.

Possible solutions:

• Analyze new business structure and build new role hierarchy
• Migrate record ownership and team memberships to new parent records
• Reset organization-wide defaults before and after changes
• Add sharing rules, then selectively remove as ownership and teams transition

☑️ Tips / Best Practices

When designing and deploying the Salesforce sharing model, keep in mind these key best practices:

✔ Simplify Role Hierarchy

Avoid modeling the formal organizational chart exactly. Instead, construct the minimal set of roles that map to required data access. Avoid unnecessary overlapping branches that create complex inheritance.

✔ Limit Skewed Record Ownership

If individual users own many records, especially on parent objects like accounts, performance issues can occur. Ideal user record to owned record ratio is 1:10,000 or better.

✔ Test in Sandbox First

Always test major changes to sharing model components like organization-wide defaults, role hierarchy, rules, teams, and territory management in a full copy sandbox environment first.

✔ Defer Sharing Recalculations

For organizations with millions of records, optimize large batch sharing operations by having Salesforce Customer Support temporarily defer automatic sharing recalculations triggered by the changes.

✔ Limit Access Skews

Watch for parent objects like accounts that have very large numbers of child records. Ideal ratio is 1:10,000 parent to child records for optimal performance.

✔ Consider Hierarchy Impact

Role and territory hierarchies confer access to descendants, but the account hierarchy does not. Account parent-child relationships do not directly control access without other components like rules.

✔ Leverage permission sets over profiles

Permission sets allow administrators to define modular, reusable sets of permissions. Rather than creating individual profiles for every user or function, build small permission sets that can be combined as needed. Reduces number of profiles to maintain.

✔ Use criteria-based sharing rules for targeted access

Criteria-based sharing rules process faster than owner-based rules. Owner-based rules require recalculation on every ownership change. Have criteria-based rules grant access to records meeting specified field values.

✔ Avoid deeply nested public groups

Public groups can be nested within other public groups. However, deep nesting like 5+ levels can impact performance during membership calculation. Keep group nesting shallow.

✔ Evaluate territory management for account/opportunity access at scale

Model teams, roles, and collaborative selling more flexibly with territory management. Provide access based on territory record assignments rather than complex sharing rules. Consider for large complex account hierarchies.

📝 Summary

The Salesforce sharing model provides a flexible architecture to customize data access across many types of users and scenarios. Planning requirements thoroughly and leveraging all available components can enable granular and high performance access configurations. Maintaining organized model documentation, testing rigorously prior to deployment, and following troubleshooting protocols will ensure long term success.