Set an Access Mode for Database Operations

Apex database operations run in user mode by default, which means that they apply the sharing rules, field-level security (FLS), and object permissions of the running user. Database operations only ignore FLS and object permissions if you explicitly set them to run in system mode.

If you set a database operation to user mode, the operation always respects the user’s sharing rules. However, if you set the operation to system mode, the sharing keyword on the calling class determines whether the operation respects the user’s record-level permissions. See Use the with sharing, without sharing, and inherited sharing Keywords.

Note

Set an Access Mode for SOQL and SOSL Queries

To indicate an access mode for a SOQL or SOSL query, insert a WITH USER_MODE or WITH SYSTEM_MODE clause. This example specifies user mode in SOQL.

1List<Account> acc = [SELECT Id FROM Account WITH USER_MODE];

In SOQL queries, user mode:

Supports polymorphic fields, such as as Owner and Task.whatId.
Processes all clauses in the SOQL SELECT statement including the WHERE clause.
Finds all FLS errors in your SOQL query.
Supports the getInaccessibleFields() method on QueryException to examine the full set of access errors.

Set an Access Mode for DML Statements

To indicate an access mode for a DML statement, insert the as user or as system keywords between the DML operator and the object name. This example inserts a new account in user mode.

1Account acc = new Account(Name='test');
2                insert as user acc;

If you run DML operations in user mode, you can use the DMLException method getDmlFieldNames() to obtain the fields with FLS errors.

Tip

Set an Access Mode for Database and Search Methods

The AccessLevel class represents the two modes in which Apex runs database operations. Use this class to define the mode as user mode or system mode.

An accessLevel parameter in Database and Search methods specifies whether the method runs in user mode (AccessLevel.USER_MODE) or system mode (AccessLevel.SYSTEM_MODE).

These DML and query operations support the accessLevel parameter.

Database.query method. See Dynamic SOQL.
Database.getQueryLocator methods
Database.countQuery method
Database.getCursor method
Database.getPaginationCursor method
Search.query method
Database DML methods (insert, update, upsert, merge, delete, undelete, and convertLead). Includes the *Immediate and *Async methods, such as insertImmediate and deleteAsync.

If you run Database DML methods with AccessLevel.USER_MODE, you can access errors via SaveResult.getErrors().getFields().

Tip

These Database methods require the accessLevel parameter.

Use Permission Sets to Enforce Security in DML and Search Operations (Developer Preview)

In Developer Preview, you can specify a permission set that to augment the field-level and object-level security for database and search operations. Run the AccessLevel.withPermissionSetId() method with a specified permission set ID. Specific user mode DML operations that are performed with that AccessLevel, respect the permissions in the specified permission set, in addition to the running user’s permissions.

This example runs the AccessLevel.withPermissionSetId() method with the specified permission set and inserts a custom object.

1@IsTest
2public with sharing class ElevateUserModeOperations_Test {
3  @IsTest
4  static void objectCreatePermViaPermissionSet() {
5    Profile p = [
6      SELECT Id
7      FROM Profile
8      WHERE Name = 'Minimum Access - Salesforce'
9    ];
10    User u = new User(
11      Alias = 'standt',
12      Email = 'standarduser@testorg.com',
13      EmailEncodingKey = 'UTF-8',
14      LastName = 'Testing',
15      LanguageLocaleKey = 'en_US',
16      LocaleSidKey = 'en_US',
17      ProfileId = p.Id,
18      TimeZoneSidKey = 'America/Los_Angeles',
19      UserName = 'standarduser' + DateTime.now().getTime() + '@testorg.com'
20    );
21
22    System.runAs(u) {
23      try {
24        Database.insert(new Account(name = 'foo'), AccessLevel.User_mode);
25        Assert.fail();
26      } catch (SecurityException ex) {
27        Assert.isTrue(ex.getMessage().contains('Account'));
28      }
29      //Get ID of previously created permission set named 'AllowCreateToAccount'
30      Id permissionSetId = [
31        SELECT Id
32        FROM PermissionSet
33        WHERE Name = 'AllowCreateToAccount'
34        LIMIT 1
35      ]
36      .Id;
37
38      Database.insert(
39        new Account(name = 'foo'),
40        AccessLevel.User_mode.withPermissionSetId(permissionSetId)
41      );
42
43      // The elevated access level is not persisted to subsequent operations
44      try {
45        Database.insert(new Account(name = 'foo2'), AccessLevel.User_mode);
46        Assert.fail();
47      } catch (SecurityException ex) {
48        Assert.isTrue(ex.getMessage().contains('Account'));
49      }
50    }
51  }
52}

Checkmarx, the AppExchange Security Review source code scanner, isn’t updated with this new Apex feature. Until it’s updated, Checkmarx can generate false positives for field or object-level security violations that require exception documentation.