2 min read

Friends don't let Friends Troubleshoot Alone

I recently had the opportunity to help a buddy of mine troubleshoot an issue that concerned Salesforce.com account shares. The error showed up on the developer message boards from years past but with no clear solution. It was only after explaining the issue to another colleague (Thanks Mike) that the issue became apparent.

First here is the error message:

System.DmlException: Insert failed. First exception on row 0; first error: INVALID_ACCESS_LEVEL, (ACC_SHARE.ACC_ACCESS_LEVEL, ACC_SHARE.OPP_ACCESS_LEVEL, ACC_SHARE.CASE_ACCESS_LEVEL, ACC_SHARE.CON_ACCESS_LEVEL) (Account, Opportunity, Case Levels, Con Levels (Read, None, None, Read) are below organization levels (Read, None, None, ControlledByParent))

When originaly troubleshooting the issue I was soley focused on the "ControlledByParent" setting of the ContactAccessLevel. Doing some digging in the docs on this it states that you can not set the contact access level if it is set to "ControllerByParent". I started to think this was the root cause of the issue for a couple of reasons:

  • I couldn't recall creating account shares for a user where the access level was "ControlledByParent" on any projects in recent memory
  • I had created shares numerous times before and the only difference that I can recall was this particular setting.

As the error message says you can't create a share with levels lower than the org-wide levels. But closer examination shows that the levels where exactly the same. It wasn't until discussing further that it dawned on me the the error message should really say "...are below or equal to organization levels".

After realizing this it seems pretty obvious that creating a share to give a user the same access rights as the org-wide permissions seems a bit fruitless and unnecessary. However, in this particular case the focus was on creating an account team entry and a share to match so the details of the access levels matching the org-wide levels was overlooked.

The solution was to double check the requirements for the org-wide defaults. Turns out the org-wide account access level should have been set to "Private" which makes adding a share with "Read Only" access much more relevant. Once this change was made the code was able to create the shares without error.

It's interesting to look back at issues like this to see how tunnel-vision can really affect your ability to troubleshoot an issue. It helps to have a circle of friends and colleagues to bounce ideas and problems off of.