Profile Setup

To start with, I have created a profile named “ReadOnly”. In the profile, I have set up the Case object access as Read and View All. No Edit, Delete or Modify All permission is given in the profile.

Example 1

With the above profile set, if I execute the below program, I will be able to see all the cases in the system.

As you can see in the above code, I am trying to fetch all the cases from the system, but there is a new parameter I am adding to the query. This is the new accessLevel parameter that you can add now to define in which mode (User mode or System mode) the apex code will execute. For example, in the above code, the soql query will execute in USER MODE.

Example 2

This time, let’s try to create the case. We know that the profile is not having the create permission. So I am expecting the execution will fail.

Now if I execute this above code, I will get the error message stating

System.SecurityException: DML operation INSERT not allowed on Case

The reason is that I am running the database operation with USER MODE, but this user/profile does not have permission to create case record.

Example 3

Now this time, I will execute the same code, but instead of USER MODE, it will be executed in SYSTEM MODE. 

As expected, the code will execute fine this time by creating a new case even though the profile is not having case create permission. The reason for that is the accessLevel mentioned as SYSTEM_MODE.

Example 4

This time, I will validate the FLS (Field Level) permission. For that I will remove the field level permission (Read) from the Case’s Subject field and then execute the below method.

Execution will fail with the error message –

System.QueryException: No such column ‘Subject’ on entity ‘Case’. If you are attempting to use a custom field, be sure to append the ‘__c’ after the custom field name. Please reference your WSDL or the describe call for the appropriate names.

The reason is with USER MODE, the apex code/soql has no visibility on the Subject field because the FLS is set to false on this field.

Conclusion

This is a very useful feature which developers can take advantage of now. But with power, comes responsibilities. So always recommended following the best practices by giving the least possible permission to any profile/permission set and then exposing as needed. 

As of now, we can use the accessLevel in the below set of overloaded System.Database and System.Search methods.

• Database.query
• Database.countQuery
• Database.getQueryLocator
• Search.query
• Database DML methods
• Database.queryWithBinds
• Database.getQueryLocatorWithBinds
• Database.countQueryWithBinds

Please read the official documentation here.

Disclaimer

This article is not endorsed by Salesforce, Google, or any other company in any way. I shared my knowledge on this topic in this blog post. Please always refer to Official Documentation for the latest information.