Sharing Rules

Purpose of sharing rules is to provide automatic exceptions to OWD for defined sets of users.

They selectively grant (wider) data access to defined sets of users than what OWD provides.

If multiple sharing rules give a user different levels of access to a record, the user gets the most permissive access level.

Rule types based on:

  • record ownership

    • owned by members of:
      • Public Groups
      • Roles
      • Roles and subordinates
  • criteria

    • field value

  • Roles and subordinates: includes all users in a role, and the roles below that role.

Let us write a criteria based rule for records of Quote__C

Questions:

1.How many sharing rules per object we can define by default?

By default, we can define up to 300 user sharing rules, including up to 50 criteria-based sharing rules per object.


2.What is the Permission need for the creating sharing rules?

Manage Sharing


3.Can we use Apex to create criteria-based sharing rules?

No. You can’t use Apex to create/test criteria-based sharing rules.


4.Can we use Metadata API to create criteria-based sharing rules?

Yes. You can use the Metadata API to create criteria-based sharing rules starting in API version 24.0.


5.Can we include hi-vol portal users in sharing rules?

No. You can’t include high-volume portal users in sharing rules because they don’t have roles and can’t be in public groups

Starting with Summer ’13, the Customer Portal isn’t available for new organizations.

High-volume portal users are limited-access portal users intended for organizations with many thousands to millions of portal users. Unlike other portal users, high-volume portal users don’t have roles, which eliminates performance issues associated with role hierarchy calculations. High-volume portal users include both the High Volume Customer Portal and Authenticated Website license types.

Performance tip:

If many users have the same record access requirements: place those users in a group and grant access to the group instead of to the individuals.

This practice saves time and results in fewer sharing rows, thus reducing your org's record access data volume