Unexplicable “level of access” error when editing Account

Question

So one of my users (with a custom profile) tries to save an edit of an Account and gets the dreaded "You do not have the level of access necessary to perform the operation you requested. Please contact the owner of the record or your administrator if access is necessary." message.

The thing is: he is the owner of the record. This should not be happening. It happens to him for a number of Accounts on production, but not for all of them.

In our partial copy sandbox, I can reproduce this behavior for just one Account, using his login. The Accounts that are not editable on production, are editable in the sandbox.

I have enabled a debug logbook, but to my dismay, it turns up with "Success" and very little information. The debug level is on finer or finest for all aspects, but the logs do not display the error. As far as the debug logbook is concerned, the edit action was successful. This is strange.

So I was thinking: duplicate management, validation errors, workflow rules, triggers, processes, but the little information that the debug logbooks give, show that this is not the problem.

When I add a contact to the Account (still being logged in as that user), the "Last modified date/by" field is updated to that user! (some system rollup summary field perhaps?) But a direct edit of the Account still fails.

We have some packages installed: Pardot, BlueConic. Maybe there is some object, related to the Account, to which the user does not have proper access. But how do I find out without debug information?

Why does the edit fail for some objects, but succeed for others, when the user is the owner of all of them?

Why do I get different results on the sandbox?

Why is my debug logbook almost empty and why does it think that the edit action was successful, when it was not?

So many questions...

Update: our org has many duplicates (because some duplicate rules were created after data import), so I thought: maybe it's a duplicate problem that is presented as a different error.

In the sandbox I cloned the account (using the /e?clone=1 trick) and saved the record: indeed I got a duplicate error message, but only 1 duplicate was shown. So the original Account did not have any duplicates. I can eliminate this possible cause.

Oh, and that clone? The edit action that is not permitted on the original Account, is permitted on its clone. So it's not the data of the Account, but something else.

Answer 1

Short answer: caused by an opportunity that is owned by someone else than the Account owner. Still don't know why edits are prohibited, though.

Long answer. I found it by experimenting with the cloned Account. All fields were equal and the cloned Account was still editable. So I looked closer and saw that the original Account has an Opportunity that is owned by someone other than the Account owner. I added a similar Opportunity to the Account and presto, the Account was no longer editable. I got the exact same error as with the original Account. I changed the ownership of the Opportunity on the cloned Account, to the same owner as the Account owner. Now I was able to edit the Account.

Inspecting the problematic Accounts on production, I found the same results. Unfortunately, it is not possible to change the ownership of the Opportunities, these are the actual owners and they should remain the owners. Other people, besides the Account owner, are permitted to create Opportunities.

Also: we use Territory Management and the relevant setting for the particular territory to which this Account belongs is:

Opportunity Access - Users in this territory can view and edit all opportunities associated with accounts in the territory, regardless of who owns the opportunities.

The Account owner belongs to this territory.

I cannot imagine this being a Salesforce bug/feature, so some custom feature (our own code or some installed managed package) is mabybe causing this.

My next move was to modify the access to Opportunities. In the OWD, it was set to Private. In the profile, read-all and modify-all had been turned off. I turned modify-all on and the Account was editable. I turned it off again (read-all as well) and the Account was still editable! I cannot reproduce the problem anymore in the sandbox, it is now behaving as expected and desired.

I have done the same in the production org and asked the user to please try again. The results are that for 9 out of 10 Accounts, the user is now able to edit them. For 1 out of 10, he still gets the same error. For that Account, the user tried to change the pertaining Opportunities, as an experiment. And for one of those, he got an interesting error message:

An error has occurred while processing your request. The salesforce.com support team has been notified of the problem. If you believe you have additional information that may be of help in reproducing or correcting the error, please contact Salesforce Support. Please indicate the URL of the page you were requesting, any error id shown on this page as well as any other related information. We apologize for the inconvenience. Thank you again for your patience and assistance. And thanks for using salesforce.com! Error ID: 1100783226-39103 (-699296067)

We have logged a case with Salesforce Support.

In the past, the Accounts have been moved from one user to another. Maybe something has gone wrong during that move, in combination with Territory Management.

Recalculating the Sharing Rules doesn't help.