In our org we have a customer community with both Customer Community (Login) license users and Customer Community Plus users.

We want to give those users access to some objects related to their account. Also, both user types should be able to create records on these objects, which then should be shared with internal users and all Community and Community Plus users of that account.

So this sharing can be divided in a couple of scenarios:
1. Created by: Internal users
1A. Shared with: Internal users
1B. Shared with: Customer Community Plus users
1C. Shared with: Customer Community users
2. Created by: Customer Community Plus users
2A. Shared with: Internal users
2B. Shared with: Customer Community Plus users
2C. Shared with: Customer Community users
3. Created by: Customer Community users
3A. Shared with: Internal users
3B. Shared with: Customer Community Plus users
3C. Shared with: Customer Community users

1A, 2A and 3A: can be easily done through OWD, sharing rules, sharing group, etc.
1B and 2B: need to be done through Apex managed sharing. I got a trigger in place which inserts the right [Object]__Share records.
1C, 2C and 3C: sharing set, defining sharing by Object:Account and User:Account.

The problem here is sharing records as a Community User to a Customer Community Plus user (3B). Whenever the trigger tries to insert the proper Shares, it throws a System.DmlException: INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY.

I know that Customer Community users don't have Apex managed sharing, but does that also mean they can't Apex manage the shares of other users of the records they own?

I've tried to get it to work using:
1. Using without sharing to ensure it runs in System Mode. No luck: it is clearly a user license issue.
2. Moving the actual DML to a Queueable. Same thing: the job is run by the same user who enqueued it, so the Customer Community user.
3. Share group. This shares all the records created by Customer Community users with all Customer Community Plus users regardless of if they are belonging to the same account. Result: CC+ users see data from other customers.

I think it related to this question but none of the answers/comments seem to solve this particular problem, on top of that the available licenses and capabilities (especially regarding communities) changed quite a bit over the years.

The only possibility I see so far is to partly implement the strategy as suggested by crmprogdev here, but instead write a schedulable job which is scheduled to be run every minute by a System Admin user to avoid the insufficient access thing. This doesn't have my preference though... Have I overlooked any possibility or is there another way to solve this exception? (I mean, it seems to be a quite common use case to have both CC and CC+ licenses who can see each others data under the same account, right?)

  • 1
    Excellent post. I have a client who is facing similar CC vs CCP sharing issues. I don't have an answer regarding Apex managed sharing, but if it can't be used, then a workaround might be to use a custom checkbox field on the object and set up criteria-based sharing rules on that field for each Portal Role. Would be a maintenance nightmare if you have lots of shared objects and portal accounts, of course. Commented Nov 23, 2017 at 18:30
  • Have you tried using Sharing Set Commented Nov 25, 2017 at 15:04
  • @DavidCheng thanks! Yes, it are quite some objects and as far as I understand that would imply setting it up for every new Account (is that right?) which is what I wanted to avoid using Apex in the first place...
    – Steven.B
    Commented Nov 27, 2017 at 8:48
  • @salesforceDeveloper sharing sets cannot be used to share records with CC+ users. You can use the corresponding sharing group, but there is no way to share records dynamically by Account (see point 3 from my post).
    – Steven.B
    Commented Nov 27, 2017 at 8:51

1 Answer 1


I finally managed to root out the cause of the problem, which was the weird fact that a record owned by a Community user can't be shared (not even manually).

I found out when I tried to view the Sharing using the button on the record and figured there was no Add button in the next screen. Reading this comment I got on the right track.

In the end was easily solved by transferring the ownership to a Salesforce (Default) user.
Furthermore I had all logic of creating the actual shares moved to a every minute running Schedulable (doing the DML in a following Queueable). This way the whole sharing operation is executed by a System Administrator user.

After this the error didn't reappear.

You must log in to answer this question.

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