• T4S Demo
  • 0 Points
  • Member since 2015

  • Chatter
  • 0
    Best Answers
  • 0
    Likes Received
  • 0
    Likes Given
  • 0
  • 1

Ran into an interesting Salesforce-to-Salesforce (S2S) problem I thought I'd share - it appears the S2S Connection Owner cannot insert share records via Apex trigger.


We have S2S configured in our org to receive Case records from another org.  Separately, we have a Case trigger to insert a custom "Performance Rating" object record anytime a Case is closed (to rate the owner).  This, in turn, fires a Performance Rating trigger to share the newly inserted record with the Case owner.


It all works fine normally.  But when a Case is closed via S2S connection, the Performance Rating trigger is failing with an INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY exception.  Apparently, the S2S Connection User isn't being allowed to insert  the new Performance_Rating__Share record.  The error occurs on the last line in the trigger below:


Trigger shareWithRelatedRecordOwner on Performance_Rating__c (after insert, after update) {
  List<Performance_Rating__Share> prShareList = new List<Performance_Rating__Share>();
  for (Performance_Rating__c pr : Trigger.new) {
    if(pr.Related_Record_Owner__c != null) {
      Performance_Rating__Share prShare = new Performance_Rating__Share();
      prShare.ParentId = pr.Id;
      prShare.UserOrGroupId = pr.Related_Record_Owner__c;
      prShare.AccessLevel = 'read';
      prShare.RowCause = Schema.Performance_Rating__Share.RowCause.Related_Record_Owner__c;
  insert prShareList;

 Note that "with sharing" isn't coming into play here, so I believe the trigger should be running in system (aka "god") mode, and it really shouldn't matter who the running user is.


My theory is that we're hitting some odd bug related to the S2S Connection User.  In my view, this trigger should always work - it shouldn't fail just because it's being invoked as the result of an update made to a record via S2S.


Our quick & dirty workaround was to simply put a try/catch around the insert, and eat the error.  But wow, that is an unsatisfying resolution (and it results in the new record NOT being shared with the original Case owner, per the intent of the trigger).


I'd welcome any alternate theories.