+ Start a Discussion

Why Object level permission are ignored in Apex class written using sharing keyword?


I have one user who has CRUD permission on Case & Read only permission on Custom Object.

When Case record is created ,in Apex class invoked through trigger user is able  to create record for custom object on which user does not have create permission. The Apex class is written using Sharing keyword.

The code in Apex class seems to run in system mode even using after sharing keyword.

Please let me know if is possible to write Apex class which obeys FLS and Object permissions.


Documentation says Apex runs in system mode and standard controller runs in user mode. If we click on save button on Case layout then how both these 2 works together? Because std. Controller runs in user mode then the trigger runs in system mode.

Please can someone clarify this?


Hi Sameer,

Apex triggers run in system mode and can therefore do any type of CRUD operations independently from which user is causing the trigger to fire - from the Apex Guide (http://www.salesforce.com/us/developer/docs/apexcode/Content/apex_classes_keywords_sharing.htm):

"Apex generally runs in system context; that is, the current user's profile-based permissions, field-level security, and sharing rules are not taken into account during code execution." and "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."


With/without sharing keywords only affect what records the user can and cannot edit/view depending on the sharing model defined in the application and apply only to visualforce controllers - this is my understanding according to the documentation:

"Use the with sharing keywords when declaring a class to enforce the sharing rules that apply to the current user."  

Since the current user is always "system" for triggers I assume that does not have any effect when executing in a trigger context.


Those keywords do not affect the FLS and object CRUD permissions.

Visualforce pages will respect the user's CRUD permissions and FLS only when the developer references  SObjects and SObject fields directly in the VisualForce page.

For custom controllers it is the programmer's responsibility to check CRUD and FLS.

Please review this wiki article for a more detailed understanding of those concepts:

http://wiki.developerforce.com/index.php/Enforcing_CRUD_and_FLS and its follow-up: http://wiki.developerforce.com/index.php/Testing_CRUD_and_FLS_Enforcement .


In summary, answering your questions:

1 it is possible to enforce CRUD and FLS only for Apex Visualforce controllers - from the first link posted above: "A user's profile-based permissions and field-level security are always ignored to ensure that Apex scripts can view all fields and objects in an organization."


2 I believe your question is best answered by looking at the above link where you can find examples of CRUD and FLS in different scenarios. I believe you are referring to this particular statement in the Visualforce developer guide:

"Note that if a controller extension extends a standard controller, the logic from the standard controller does not execute in system mode. Instead, it executes in user mode, in which the profile-based permissions, field-level security, and sharing rules of the current user apply."


I think the answer is in one of the scenarios explained:

"If you are using controller extensions and intend to delete the active record, another option is to call the standard controller's delete() function instead of deleting the object within the controller extension. The standard controller will automatically check CRUD access before performing the operation." The trigger has got its own execution and security context: system.


Hi Sebcos,


Can you explai me this in details please.....


As you said, apex runs in "system mode" which does not consider current user permissions and field level security and sharing rules, which is good thing for triggers and apex, where they need to use all rocrds.


But, there migt be chance of exposing sensitive data to other users. so we use "with sharing" keyword which considers current user permissions.


and "without sharing" keyword also will not consider current user permissions like apex in "system mode". In this case whts the need to use "without sharing" keyword.


We can write no keyword in apex, then apex runs in system mode.




Neha AggrawalNeha Aggrawal

With the new feature released in Winter '19, now we can strip the fields which are not accessible by the user. More details are available on the below link: https://releasenotes.docs.salesforce.com/en-us/summer19/release-notes/rn_apex_Security_stripInaccessible.htm

I have also explored this feature in this post: https://initaura.com/field-level-security-in-apex/

Hope this helps.
Thanks and Regards, 
Neha Aggrawal
www.initaura.com - Everything Salesforce