I have explained in a previous post the sharing-related differences between Customer Community licenses (or Customer Community Login licenses) and Customer Community Plus licenses. If you are leveraging the non-plus variety, you may have to get slightly creative with your approach. To achieve “super user” like access, again, check out that previous post.
Sometimes, you want to do slightly more than a basic sharing set, but, you know… you have to use a sharing set. Let’s use an example where we want to share Cases where the Account on the Case matches the Account the Customer Community User is on. Cool so far, use a standard sharing set, that’s what they are for. Then you want to go one step further and hide Cases with a Status of “Internal”. Well, sharing sets use lookup relationships, and this includes custom relationships. So my solution here is that we want to establish a sharing set on a custom lookup, and then populate that lookup conditionally with the Account on the Case. It looks like this:
As always, I was looking to solve the problem with as little code as possible. I admit, I did not try Process Builder, perhaps the population of the custom lookup field could be accomplished without any code at all (let me know if you try it). In our case (pun intended, but not funny) we already had a Case trigger so it was easy to drop a few extra lines into it, like so:
for(case c: Trigger.New){ //here we will populate or clear the field that controls if community users can see the record if(c.Share_with_Customer__c){ c.Account_to_Share_With__c = c.AccountId; } else{ c.Account_to_Share_With__c = null; } }
I learned that (as documented) the formula does indeed seem to be updated at the time you access Trigger.New. If you are messing with fields in the trigger that are included in your formula, you may need to call the SObject.recalculateFormulas() method. However, beware that this method can’t be used if you are using cross object references. The cool part is that once you have this set up, you can change your criteria in the formula field without the need to deploy a change to your code.
thanks for this solution it works great, I can confirm that the use of a process flow works so 0% coding required.
great option for a sensitive issue.
Added extra bells n whistles to the 1 process flow to be able to toggle the viewing on and off during any edit and untick the validation if it wasn’t a valid selection allowed (were using record type as primary segmentation)