Salesforce Certification: Sharing and Visibility Architect

Notes taken in preparation for the Salesforce Sharing and Visibility Certification exam.

Role Hierarchy

• Soft limit of Org Roles is 500
  • Can be increased by SFDC
  • Best practice is to keep non-portal roles to 25k or less, and portal roles to 100k or less
• As a best practice, try to keep role hierarchy to no more than 10 levels of branches
• “Role hierarchy is the foundation for the entire sharing model.”

Public Groups

• Some “best practices”:
  • No more than 5 levels of Group nesting
  • Keep total number of public groups to less than 100k

Sharing Rules

• Ownership-Based Sharing Rules
  • Allow for exceptions to org-wide defaults and the role hierarchy, giving additional user access to records that they don’t own
  • Criteria for sharing records with others is based on the record owner’s attributes only
    • E.g., If an Account record’s owner is in Role X, then share it with members of Role Y
• Criteria-Based Sharing Rules
  • Provide additional access to records (overriding the org-wide defaults) based on criteria set up and driven by a given record’s field values
    • E.g., If an Account’s Type field == ‘Partner’, then share it with X group of people
  • Best practice to keep # of Criteria-based sharing rules to 50 / object

Manual Sharing

• Manual sharing is removed when the record owner changes
  • ”… or when the sharing access granted doesn’t grant additional access beyond the object’s Org-wide defaults”
    • Unsure what this means…
• According to document, seems like Manual Sharing is controlled by an objects Share records
  • Only “manual share” records can be created on standard objects
    • I.e., Share records with “Row Cause” = “Manual Share”

Team-based Sharing

• Only record owners, people higher in the hierarchy and Admins can add team members and provide more access to members
• Create a team member creates two records:
  • Team record
    • Note: Not a first-class object; you can’t create custom fields, triggers, or validation rules on this object
  • Associated Share Record
• Only 1 team per record
  • If additional “teams” are needed, consider territory management or programmatic sharing

Territory-based Sharing

• When you enable territory management, you must enable both Role-based hierarchy and the territory hierarchy (additional, single-dimensional hierarchy)
• Exist only on Account, Opportunity, and Master/Detail children of Accounts & Opps
• If assignment rules for a territory are changed, sharing rules using that territory will be recalculated
• Interesting use cases for using territory-based sharing:
  • Multiple groups of people (multiple teams require read or read/write access to Accounts)
  • Single user needs to hold multiple levels in the “hierarchy”
• Account Territory Sharing rules are only available when territory management has been enabled

Programmatic Sharing

• References creating Share records via Apex
• If you create a Share record programmatically and leave the default Row Cause value (“Manual Share”), then the share record can be maintained via the “Share” button in-app
  • These records are also subject to all rules with manual share records, like deletion upon record ownership transfer.

Implicit Sharing

• Doesn’t apply to custom objects
• Parent Implicit Sharing: providing access to parent Account records when a user has access to child Opps, Contacts, or Cases
• Child Implicit Sharing: providing access to an Account’s child records to the Account owner, defined at the User’s role in the role hierarchy (either View, Edit, or No Access)
  • Only applies to Opps, Contacts, or Cases

Sharing Sets

• Used to share records with External Users (community members) based on the Account / Contact record associated with their User record
• There is a list found here of supported objects that you can use in Sharing Sets
  • Important Note on What’s NOT Supported: Objects with OWD set to Public Read/Write (I’m assuming externally?) aren’t supported; nor Custom Objects without a lookup to the Account or Contact object

Encryption Settings

• Great comparison table found here comparing Shield Platform Encryption vs. SFDC Classic Encryption
• Classic Encryption: Personal notes on Salesforce Classic Encryption
• Shield Platform Encryption: Personal Notes on Shield Platform Encryption

Misc. Notes

• If a single User owns more than 10,000 records, then consider the following best practices:
  • This user should NOT hold a role in the role hierarchy
  • If the user MUST hold a role, the role should be at the top of the hierarchy in its own branch of the role hierarchy

Other Related Topics

• Security
• Data Security
• Compliance