Salesforce “Inherited Sharing”, explained!

Salesforce “Inherited Sharing” is a newly introduced modifier for class declaration. It’s surely better than Apex classes with no sharing declaration, as it mostly enforces WITH SHARING context, the official documentation screenshot describes Aura, VF, and Apex REST to auto enforce WITH SHARING context. But it’s ambiguous about any other entry point to an Apex transaction:

Inherited Sharing Experiments (Video Walk-through)

The following video demonstrates INHERITED SHARING’s impact in various contexts i.e. Aura, Batch, Inbound Email Handler, Scheduler, Trigger, Invocable Actions, Apex REST Service.

Following is summary of my findings, please note the Apex Trigger context is the exception.

Inherited sharing implications from various Apex Entry points

Summary

Please be alarmed when using INHERITED SHARING with TRIGGER as Apex Entry point. As that’s the only situation where it acts in WITHOUT SHARING mode. Hopefully, this is the correct approach for Triggers, as they need to see more than usually visible data, i.e. beyond the sharing rules for a given user.

There is a similar expectation with Invocable Actions, as they are used in Process Builder to coverup complex business logic requirements. But they are executed in WITH SHARING mode. Same goes with Batch/Scheduled apex, its meant to see all data beyond usual sharing rules, but it’s working in WITH SHARING mode. Thus, be cautious and use correct INHERITED, WITH or WITHOUT sharing mode on Invocable, Batch, and Scheduled Apex.