OK, I know how to debug this error and there are plenty of web resources to assist so please don't answer with those techniques.
What I'm more after is why the ID value in []
is typically null for this error when you know that the cross-reference ID has a value and if the error message just emitted the ID, you would know what SObject was the root cause, gaining valuable minutes/hours for your life.
Here's an example:
- OWD private on
Account
Order
is controlled by parent- running user profile has Modify All, View All on
Account
and View All onOrder
. Running user can view the Order via the UI.Modify All
does not cascade down to Order even withControlled by parent
. - Apex code attempts to insert a custom object
Order_Detail__c
underneath (not Master-detail)Order
, providing a value for lookup fieldOrder_Detail__c.Order__c
Now because there's no sharing rule extending r/w to the Order's Account in question, there's no r/w access to the Order and hence the INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY, insufficient access rights on cross-reference id: []
error occurs when attempting to assign the child record to the parent Order.
What I don't understand is why the ID value of the field Order_Detail__c.Order__c
lookup field is not emitted in the error message within the []
. Why are the brackets even there?
I suppose this is a security item and not exposing the ID value avoids telling the malefactor even what SObject can't be accessed. I'd be happy if the error message just displayed the first three chars - or converted to an sobjectType. The implication of []
is an empty array . but that is not what is going on in your code.
Is this hypothesis correct?
It sure makes life hard for the sysad who captures a debug log for the running user and then has to go through feats of deductive logic to figure out which related sobject (there could be several lookup fields on the object in question) is the problem one, let alone why.
FIELD_INTEGRITY_EXCEPTION
,REQUIRED_FIELD_MISSING
, andFIELD_CUSTOM_VALIDATION_EXCEPTION
(specifically for validation rules with an errorDisplayField). These seem to be errors where a constraint on the field itself is violated. I don't know the developers' intent, but it might be that insufficient access to another object is not considered to violate a lookup field referencing that object. Put another way, there wasn't a problem with the data in the record you were updating, but with the user doing the update. It wasn't caused by any field.