I found this post (Sharing rules and Inner classes), which references documentation that inner classes do not inherit the sharing of their container class.

From the documentation:

Both inner classes and outer classes can be declared as with sharing. Inner classes do not inherit the sharing setting from their container class. Otherwise, the sharing setting applies to all code contained in the class, including initialization code, constructors, and methods.

This makes sense to me, and I was fine with this because I wanted to implement a separate, private inner class anyway specifically designed to bypass sharing in some situations within the service class. I thought that this would be more elegant than creating a separate, dedicated without sharing class.

However, in my testing, I'm finding that the end user is still receiving an INVALID_CROSS_REFERENCE_KEY, invalid cross reference id error when running new WithoutSharing().updateObjRecords(list) when they only have read-only access to the objects in question.

The below code is an example of the scenario I'm trying to implement, but sharing seems to still be applied. Am I missing something here? Should this be possible, or am I going to have to create a separate Service class specifically designed as without sharing?

public with sharing class ObjectAService {
  public static void updateDaysSinceLastCalled(
    List<OBJ_A__c> objList,
    Map<String, DateTime> recordMap
  ) {
    // Do Logic (Removed for Brevity)

    if (!list.isEmpty()) {
      new WithoutSharing().updateObjRecords(list);

  private without sharing class WithoutSharing {
    public void updateObjRecords(
      List<OBJ_A__c> lstRecordsToUpdate
    ) {
      update lstRecordsToUpdate;
  • i definitely use Inner Classes declared without sharing to elevate privileges so I doubt it is inner class-specific. Does the running user have Read permission on the object and FLS on the lookup field?
    – cropredy
    Feb 17, 2022 at 3:06
  • @cropredy the user has Read/Edit access to the object being updated by the DML, the object is the child of a master-detail with Account as the Master, so the lookup is accessible to them by definition. The user also has Read/Edit to Accounts, Accounts are OWD Private, and sharing rules grant the User Read-Only access to this particular account (and therefore, the detail records). The use case is that, upon saving a Call__c record to the Account, apex should update some details on the detail object (OBJ_A__c). Feb 17, 2022 at 13:41
  • Note that criteria-based sharing rules aren't evaluated / considered in test methods. Could this be it?
    – cropredy
    Feb 17, 2022 at 15:17
  • @cropredy this is failing in a manual test via UI while logged in as the user. I've just noticed that there's another lookup relationship on the object in question, and the user doesn't have FLS/OLS to that lookup / object... however my understanding is that shouldn't matter when using w/o sharing, am I wrong there? Feb 17, 2022 at 15:43
  • Updating requires obtaining locks on related parent objects. It is an easy experiment for you to try
    – cropredy
    Feb 17, 2022 at 16:35

1 Answer 1


After much debugging, this issue actually ended up being completely unrelated to the code and was instead a Sandbox data issue. Some of the required lookup fields had values populated which didn't exist anymore, resulting in the error.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .