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.