1

I have a custom object, Ticket__c, that has a master detail field to Contact. I have a Digital Experience accessed by "Customer Community" licensed users. One of the pages provides access to the related list of Ticket__c records for the Contact related to the given Community User.

The org's OWD sharing of "Account and Contract" for External Users is "Private", and "Contact" is "Controlled by Parent".

The Community User's profile ensures that the user has permission to create Ticket__c records with all necessary fields and has Read and Edit access to Contact.

The Related List page in the digital experience (community) appropriately provides a "New" button and clicking it shows the creation form with the master detail Contact lookup field pre-filled with the user's related Contact. However, an attempt to save the record results in "insufficient access rights on cross-reference id" (rather annoyingly this error message gives no hint as to which field or ID this relates to, but I have narrowed it down to the Contact master detail).

Now, I'm quite certain it is all related to the sharing on Account being Private and the fact that Account is the parent of Contact from the sharing perspective in the community context.

I've found some other references to this issue, including an unhelpful knowledge article, along with this other Stack Exchange Q&A where a relatively recent answer talks about providing Modify All permissions to work around the problem. This isn't a suitable solution for me so I continued looking at what I could do here.

Salesforce supports the idea of Sharing Sets for community use, accessible in Setup under Feature Settings > Digital Experiences > Settings, that seemed like a plausible solution so created a Sharing Set against Account determining access using User:Contact.Account = Account.Id, granting Read Only access (I don't believe the community user needs to be able to edit, only read).

Unfortunately this didn't help. On revisiting this configuration I noticed a second tab, "Share Group Settings" and found that there was a button to Activate the Share Group. So I clicked it.

I waited a few minutes (the scratch org I'm on has next to no data on it at this point so thought this shouldn't take long) and tried creating a Ticket__c again but still got the same error.

Anyone got any ideas as to how I can solve this problem without having to inappropriately share Accounts?

7
  • have you tried granting more access in that sharing set? Does the account have any rollup fields or anything similar related to contacts? Apr 30 at 22:51
  • AFAIK you will have to reference the Account in the sharing set. Exposes less than "View All".
    – Keith C
    May 1 at 7:40
  • Hey @KeithC can you explain more? That I basically what I thought I was doing with the Sharing Set...
    – Phil W
    May 1 at 8:59
  • Hi @KrisGoncalves what do you mean by "more access"? Do you mean write instead of read only? I am not aware of any roll ups but I will check.
    – Phil W
    May 1 at 9:00
  • Hi @PhilW, Yes I'm saying use the sharing set and I have that working - using User:Contact.Account = Account:Id - in a community for a similar setup. Presume your sharing set is tied to the right profile? Beyond that I don't know what the problem could be.
    – Keith C
    May 1 at 9:29
3

Has per @KrisGoncalves's comment, I updated the Sharing Set to allow Read/Write for the selected Account and it started to work.

UPDATE:

I realized why read/write sharing is required for Account. Since Account is the parent (in sharing terms) for Contact and Contact is the master details parent for Ticket__c, I actually have to have write sharing on Account to have write sharing on Contact and write sharing on Ticket__c. In effect, the error was a bit misleading and was essentially saying I couldn't create my Ticket__c object because I didn't have write permission for any Ticket__c - the Contact isn't owned by me, as a community user, so isn't write shared with me (and thus in turn I have no way to manage master detail children regardless of profile permissions) unless and until its parent is write shared with me in this scenario.

0

My wild ass guess is that Contact has a required standard field that's can't be written to.

And to find the exact field - put the logic into a unit test.

Start with a method that has one runas user - the customer community user. Duplicate the problem.

Then fix that with a method that has two runas users - one with a customer community profile - and another for the saving user having a profile that has "modify all data".

Once you know what the field is - and you have a "fix" - you can go down the path of making the field writeable. Might not be easy.

1
  • I did not need to change any permissions on Contact or Account, but rather make the Account write sharing.
    – Phil W
    May 4 at 6:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.