5

I have a case record which I have shared with few other users manually. But when owner of the case is changed/assigned to a sales rep then all those sharing goes away and default sharing applies. Has anybody faced similar issue. Any thoughts to resolve?

2
  • this is not an issue.. this is how it works..
    – Sam
    Commented Sep 14, 2013 at 8:29
  • @theGreatDanton okay is there any workaround by which I can persist previous sharing?
    – doga
    Commented Sep 14, 2013 at 8:57

3 Answers 3

6

You can persist them through the use of asynchronous code; basically, we store the state of sharing before the ownership change, then restore it afterwards.

First, we need a utility class for the future method:

public with sharing class Persistence {
    @future
    public static void persistSharing(String ShareString) {
        CaseShare[] reasons = (CaseShare[])JSON.deserialize(shareString, CaseShare[].class);
        for(CaseShare reason: reasons)
            reason.Id = null;
        Database.insert(reasons, false);
    }
}

Then, we create a trigger:

trigger CopyShare on Case (before update) {
    Set<Id> caseIds = new Set<Id>();
    for(Case record: Trigger.new)
        if(record.OwnerId != Trigger.oldMap.get(record.Id).OwnerId)
            caseIds.add(record.Id);
    Persistence.persistSharing(
        JSON.serialize(
            [SELECT Id, CaseAccessLevel, CaseId, RowCause, UserOrGroupId 
             FROM   CaseShare 
             WHERE  CaseId IN :caseIds AND 
                    RowCause = 'Manual']));

}

Note that we can only back up and restore manual shares. Other types of shares, such as from sharing rules or teams, are managed by the system.

8
  • Thanks for the reply. Actually I did the same but in after update trigger (synchronous call). But didnt work. Have your tried your solution?
    – doga
    Commented Sep 14, 2013 at 14:29
  • Yes, my version works.
    – sfdcfox
    Commented Sep 14, 2013 at 14:36
  • one doubt, does future method execute after transaction completes? What is their order of execution?
    – doga
    Commented Sep 14, 2013 at 17:50
  • Future methods execute after the transaction performs its final commit (after sending emails, etc). See Order of Execution
    – sfdcfox
    Commented Sep 14, 2013 at 17:58
  • 1
    @PranayJaiswal During my original research, I found that sharing was recalculated some time after the triggers finished running, and as a result, doing anything during the trigger was a pointless exercise because they'd be wiped out. I'm not sure that's true five years later, so I'd have to build a new experiment, but I suspect it still probably works that way.
    – sfdcfox
    Commented Jun 29, 2018 at 12:51
1

Following up with SFDCFox's reponse about when the shares get deleted, I have found that the shares get deleted in between the Before and After contexts, so running the logic for recreating the shares in an After context should allow us to persist the Share records, with manual row cause, in this case.

The response that has been marked as Correct Should be updated to have the the trigger run in the After Update context for clarity.

-3

This isn't the correct way to solve this. You should instead create a custom button that allows you to pick the users you want to share the record with and then insert share records for the case with a custom RowCause. (Define the RowCause) on the Case object before doing this. Once the shares are inserted using a custom rowCause, changing owner will not remove access from the shared users.

Use this for reference:

https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_bulk_sharing_creating_with_apex.htm

3
  • Note the detail: "Apex sharing reasons and Apex managed sharing recalculation are only available for custom objects." So you can't use a custom sharing reason on Case.
    – Charles T
    Commented Jun 29, 2018 at 12:14
  • Am sorry it cant be done for case, or standard object. Am downvoting for being incorrect. Commented Jun 29, 2018 at 13:03
  • This would only work for Custom objects, Standard objects (such as case, account, etc.) do not support apex sharing reasons and so this answer is incorrect in this context.
    – sevargdcg
    Commented Jul 27, 2021 at 16:43

You must log in to answer this question.

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