Some considerations about sharing

There are some peculiarities and exceptions regarding the sharing model that you should be aware of.

The following are the peculiarities and exceptions regarding role hierarchy-based sharing:

Contacts that are not parented to any account are inherently private, so they are visible to their owners and administrators. For this category, contact sharing rules are not applied.
The same happens for notes and attachments with the Private flag enabled, which are visible only to the user who created them (and administrators).
Events marked as Private are only visible to their owners and administrators.
Role hierarchy is effective on users above them in the hierarchy, but only if they have the Read or Edit permission on the given object.

Regarding object deletion, a record can only be deleted by its owner, administrator, users above them in the hierarchy, or any user that has been granted full access sharing. For cases and leads, even though a user has public read/write/transfer access, only the owner (and administrator) can delete that record.

To add notes and attachments to a record, you should have read/write access to it and at least read access so that you can create activities or associate a child record with it.

When dealing with large datasets, consider changing the sharing model can have an impact on your system due to it having to recalculate the access level across your organization, which may take several hours to complete.

If you have more than 2 million accounts and have set up account teams and territory management, take a closer look at performance to ensure that you don't have any inherently complex sharing calculations that can cause long-running transactions.

If you need to bulk change the sharing model, you can ask the Salesforce Support team to activate the defer automatic sharing rule calculations feature. With this in place, you can make all the changes you need on the OWD/sharing model and then execute the bulk recalculation when administration work has finished.

Avoid having a small number of accounts with thousands of contacts, cases, or opportunities. This is called data skew, and it can cause performance degradation. Keep this in mind and make accounts have a children ratio no greater than 1:10,000 (the less the better). This also occurs with ownership skew, which is when a few users hold ownership of thousands of objects. If this happens, make sure that the user is out of the role hierarchy (the user's role field is not filled in) or it has a higher role (for example, CEO). This simplifies sharing calculations.

A final suggestion is not to consider account hierarchies related to sharing. If a user owns a parent account, this doesn't mean they can have access to the child accounts; they aren't related to role or territory hierarchies.

Table of Contents for Some considerations about sharing

Create new playlist

Sign In

Sign Up

Table of Contents for
Some considerations about sharing