Founder of Technical Potpourri, Co-Founder of Shrey Tech, Enterprise Cloud Architect
Apex code runs in System Mode by default, with elevated access. If you want to run apex code respecting the running user’s permission, now after Spring 23 release, you can do that. With Spring 23 release, Salesforce is bringing the option to execute apex Database and Search methods in user mode instead of default system mode. In this blog post, I will share some examples, but if you prefer to watch videos instead of reading the post, you can do that by watching the video below, which I have published on my Youtube Channel – Technical Potpourri.
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.
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.
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.
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.
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.
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 DML methods
Please read the official documentation here.
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.
Thank you for the post. I was not aware of this new feature. going to share with my team.
Thank you Kevin. Please let me know how your team is going to use this feature.