function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion

Customer Portal Error "insufficient access rights on cross-reference id"

I've searched here and seen a number of posts with the above error, but I haven't found anything that addresses my issue with it.  When Customer Portal users create a case and select a contact for the case from their account, the case will not save and gives the error, "insufficient access rights on cross-reference id".

The system will only let them create cases with themselves as the ContactName (and owner).  If I then try to reassign within SF (Sys Admin) I cannot change the contactname to anything other than the Customer Portal owner.  If I do and save it, the system changes name right back.  The Customer Portal profiles have read/edit permissions.  I've also looked through the Field security and don't see anything at all.  Help!?
This is caused by a bit of a spider web of issues.  Do you presently have a public sharing model on Contact?

Basically, your Customer Portal users are attempting to assign a contact to the case that they're not supposed to be able to see in the first place.  You may be able to ameliorate this in the short term by manually sharing each Customer Portal user's account to himself, which would share the Contacts to him -- that might fix it.

In Spring '09 though, there will be a new setting on portal users' profiles called "Portal Super User" which will allow these users to see all cases and contacts in their account.  This will likely fix your problem conclusively.

Thanks for response. Well, it seems that it should work even without super user because the Portal user is just trying to select a contact within the account he's already a part of.  Portal user is from Account A and Contact is also from Account A.


I tried changing sharing model to Public and also tried sharing account to himself, and neither seemed to work.


I am trying to configure a Customer Portal and I too get this error. My org wide sharing setting is Public for Account entity and I created a new Sharing rule to share all accounts owned by CEO and Internal Subordinates with roles in Portal User but to no use :( 


Can someone help me out on this?  

Well did you enable Portal Super User or Delegated Portal User Admin as I mentioned above?
And you really shouldn't have public sharing on Account with a Customer Portal.

I'm the original poster of this issue, and I frankly think it is a bug.  Even though Warewolf mentioned the super user...that didn't fix the issue.  We opened a case with SFDC in Spring and they essentially felt that it was a bug.  Just recently, I hired a programmer to look at it and, as of 12/17, she didn't get it.


Additionally, I was at DreamForce and tried to discuss this in my 1-1 session with a SFDC expert and as soon as I mentioned "Customer Portal" eyes rolled a little as they realize there are a few issues in some areas.  If my programmer gets it next week, I'll post again.  She's playing with all kinds of sharing rules in our Sandbox but, the initial sharing rules we had set up...should work.


I think the issue is that the Portal security cannot look 2 levels down.  So, for us, the issue is a custom object tied to Contact.  Since Contact is (correctly) controlled by Parent, the sharing can't then look at the custom object and essentially apply the sharing that is tied to the Account (2 levels up).

Well that isn't a bug.  If you want a portal user to be able to see some data which isn't Controlled By Parent from Account then you'll have to set up a share to that portal user, either manually or with a sharing rule, or have it be Controlled By Parent from Account and then share each portal user's account to him.

This still doesn't work though.  We have tried all combinations of things that should work and just had a SF Certified person from Solvate look at it.  She too concluded this is a bug.   The system just doesn't let you do it...though it should. The shared items are there is evidence that the sharing is somewhat working, but the item cannot be selected. 


We've been using SF for 4+ yrs and were one of the early adopters to Person Accounts and tried setting this up in the beginning and now I'm sure it's a bug.

Did you try turning on Delegated Portal User Administrator for a portal user and seeing if that user could see the other accounts?  There are some restrictions in Customer Portal as to who can see accounts other than his own, but DPUA users can see other accounts for sure.

Hadn't tried that but...nope, same issue.  The reason still think it's a bug is that the user CAN see the other account AND contact, even without the delegated super user.  Using regular sharing rules works fine there.  What the user can't access, in this case, is the custom object Verification.  Verification is controlled by Parent (Contact) which is also Controlled by Parent (Account).  So since user sees the correct Account and Contact...should also be able to see the Verification.


Customer Portal (CP) user CAN see verification object for their own account so issue has nothing to do with whether object is correctly exposed to CP users.


We had same issue with another custom object that had same setup.


still doesn't work with delegated and super user on.


I am trying to create a Note and attach it to a Contact record.

I FINALLY got confirmation that this is indeed a bug. We recently upgraded to Unlimited and I got Premier support to look at it.  They have been talking with me for about 3 weeks.  They said that it looks like it's fixed in Spring '10.  We arent upgrading to that till March so we'll see what happens.  They did confirm that it's not supposed to behave this way.



how did you go with this?  Has it been fixed in Spring '10?

Yes, it is fixed in Spring 10

I am getting the same error...Error: insufficient access rights on cross-reference id


Can you describe what you did to resolve this...thanks


Update:  I set Accounts to Private and then created sharing rules to share Accounts back to internal users.  These seems to have resolved it.