Newer Version Available

This content describes an older version of this product. View Latest

Enforce Sharing Rules

Apex generally runs in system context, so the current user’s permissions and field-level security aren’t taken into account during code execution. You can use sharing rules to extend a user’s access to specific records, and then enforce sharing rules by using the with sharing keyword on a class declaration. If you declare a class with the without sharing keyword, then sharing rules aren’t enforced.

Apex code that is executed with the executeAnonymous call and Connect in Apex always execute using the sharing rules of the current user. See Anonymous Blocks.

Note

Apex developers must take care not to inadvertently expose sensitive data that would normally be hidden from users by user permissions, field-level security, or organization-wide defaults. They must be particularly careful with Web services, which can be restricted by permissions, but execute in system context after they’re initiated.

Most of the time, system context provides the correct behavior for system-level operations such as triggers and Web services that need access to all data in an organization. However, you can also specify that particular Apex classes should enforce the sharing rules that apply to the current user.

Enforcing sharing rules by using the with sharing keyword doesn’t enforce the user’s permissions and field-level security. Apex always has access to all fields and objects in an organization, ensuring that code won’t fail to run because of fields or objects that are hidden from a user.

Note

This example has two classes, the first class (CWith) enforces sharing rules while the second class (CWithout) doesn’t. The CWithout class calls a method from the first, which runs with sharing rules enforced. The CWithout class contains an inner class, in which code executes under the same sharing context as the caller. It also contains a class that extends it, which inherits its without sharing setting.

1public with sharing class CWith {
2  // All code in this class operates with enforced sharing rules.
3
4  Account a = [SELECT . . . ];
5
6  public static void m() { . . . }
7  
8  static {
9    . . .
10  }
11
12  {
13    . . .
14  }
15
16  public void c() {
17    . . .
18  } 
19}
20
21public without sharing class CWithout {
22  // All code in this class ignores sharing rules and operates 
23  // as if the context user has the Modify All Data permission.
24  Account a = [SELECT . . . ];
25  . . .
26
27  public static void m() {  
28     . . . 
29
30    // This call into CWith operates with enforced sharing rules
31    // for the context user. When the call finishes, the code execution 
32    // returns to without sharing mode.
33    CWith.m();
34  }
35
36
37  public class CInner {
38    // All code in this class executes with the same sharing context
39    // as the code that calls it. 
40    // Inner classes are separate from outer classes.
41    . . .
42
43    // Again, this call into CWith operates with enforced sharing rules
44    // for the context user, regardless of the class that initially called this inner class.
45    // When the call finishes, the code execution returns to the sharing mode that was used to call this inner class.
46    CWith.m();
47  }
48
49  public class CInnerWithOut extends CWithout {
50    // All code in this class ignores sharing rules because
51    // this class extends a parent class that ignores sharing rules.
52  }
53}

Because a class declared as with sharing can call a class declared as without sharing, you may still have to implement class-level security. In addition, all SOQL and SOSL queries that use Pricebook2 ignore the with sharing keyword. All price books are returned, regardless of the applied sharing rules.

Warning

Enforcing the current user's sharing rules can impact:

  • SOQL and SOSL queries. A query can return fewer rows than it would operating in system context.
  • DML operations. An operation can fail because the current user doesn't have the correct permissions. For example, if the user specifies a foreign key value that exists in the organization, but which the current user doesn’t have access to, then the DML operation fails.