At the moment we have a customer portal and we are looking to move to communities. The Customer Community license and the Customer Community Plus license offer different options for the sharing of the data. That's why we are investigating the options.

The current portal makes use of the sharing sets. There are 9 profiles for the portal and on each custom object there are 9 account lookups. Each profile has its own lookup. Via the sharing sets we are able to define that the user has access to the data when the user's account is set in the corresponding lookup on the custom objects.

So as a portal user you can only see the data of your own account. In certain cases you should also see data from another account. It isn't possible to make the sharing sets look at more than 1 lookup, so we made a profile switch. This is a workaround and we would like to get rid of it.

The Customer Community license also works with the sharing sets, so that would put us into the same situation. The Customer Community Plus license would give us the ability to use apex sharing. The original idea was to give access to the data of the own account via the sharing sets and use apex sharing to give access to the data of another account. This isn't possible, since you can't use sharing sets with Customer Community Plus.

It means we would have to use apex sharing for everything. We have like 8 different custom objects and considering we have 3 custom objects with a lot of records (33 million, 27 million and 11 million), that's going to result in a lot of sharing rules.

Does anyone know if there is a limit on the amount of apex sharing rules? Would there be any performance issues (due to the amount and in the case of sharing recalculations)?

Did anyone faced a similar situation before and in which way have you done your setup?

Thanks in advance.

1 Answer 1


You're correct that the Customer Community Plus license is very different than the standard Customer Community and Partner Community licenses when it comes to their sharing models. You will still have a certain amount of External Sharing vs Internal Sharing that you can configure, but as you say, you can't use sharing sets in Customer Plus Community. That having been said, Apex Sharing, offers you unlimited sharing capabilities, capabilities that either don't exist or just aren't possible within a standard Customer Community.

First, you can create up to 10 Apex sharing reasons per custom object. You don't need to create "explicit reasons" for each record you share. The logic in your code will be doing much of that for you (remember to write your code to unshare records too). Most of it, as I've viewed it in my experience, was along the lines of "related record", "related to account", "related to contact/user/case/record", etc or however else you'd like to describe it depending on context; assuming you don't want to use the default sharing reasons available to you.

The issue then becomes do you want to do the sharing in real time or asynchronously. If asynchronously, do you want to write to a temporary object from a trigger or do you just flag the record? Then, do you run a batch class or do you or use queueables fired from a trigger?

If the latter, I recommend you look at Dan Appleman's pattern in Ver 3 of his Advanced Apex Programming book (released Sept 2015). I used the pattern recently in a very large community+ apex sharing implementation project where the community itself is still in development. I think it's a good pattern. But, it really comes down to having a robust trigger pattern, error handling, plus record processing that can intelligently process and deal with any issues that are encountered with the asynchronous data.

  • I could create a common Apex sharing reason on the objects, but it still means I will have millions of apex sharing rules. Apart from the sharing sets, none of the standard sharing options seem to provide a way to do the following: User:Account = Equipment:Customer__c, unless I am missing something?
    – svenf
    Commented Feb 23, 2016 at 12:23
  • I'm not following your criteria here. What do you want to share with who and what are your criteria? Use a trigger on the object that relates the criteria. You may need to go through other objects using queries to determine if they meet your criteria. For example, you'd normally need to go through a community user's contact record to get to their Account record to make other connections. Does that help? The share record is on the object record that's being shared, but only one rule is needed. If sharing lots of records, you'd have lots of share records, not rules.
    – crmprogdev
    Commented Feb 23, 2016 at 13:53
  • On all the custom objects there is a lookup to account. The portal user should have access to all the records where the account lookup contains the account of the portal user. Yes my mistake, I mean share records instead of rules.
    – svenf
    Commented Feb 23, 2016 at 14:07
  • Sounds like that should be fairly easy to implement. When a new portal user is created, all account records for his account are search and shared with him. When any new record is created, all portal users with related accounts get shares created for them on that record. This basically means you'll need a very good enterprise level trigger platform with error handling and a means of processing those shares either immediately or asynchronously. I'd do it asynchronously using queueables if it were me.
    – crmprogdev
    Commented Feb 23, 2016 at 14:14

You must log in to answer this question.

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