we have the following setup:

  • Private sharing model on the Account object
  • Sharing rule to share Account records with role and subordinates based on the Account record type field

The task

Update Account record after Lead conversion without additional async call using Apex (with sharing). Basically, two actions to do:

  1. Convert lead using Database.convertLead method
  2. Update a few fields in the new converted Account record

The problem

We have a lead record, where the owner is a different user. But it's under the same role. So, converted records are available to view/edit under the current user via Salesforce UI.

When we convert it in Apex, it's not possible to update the Account record. We could not query the new Account. Also, the "hard" update with setting account id doesn't work as well:

Update failed. First exception on row O with id 0012500001z7HUAAI; first error: INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY, insuffic ient access rights on cross-reference id: 0012500001zs7Hu

Our idea that is because Salesforce executes sharing rules almost at the last step based on the order of execution. But we are not 100% sure that the reason.

What do you think?

  • This is probably lead conversion shenanigans. Do you face the same if you run the Acc update in a separate transaction?
    – Al Cher
    Mar 17 at 15:16
  • @AlCher account update in the second transaction works good. Mar 17 at 15:22
  • My guess is when you use convertLead() SF locks the account for editing in the transaction to ensure data consistency. Kinda similar to how you can't make callouts where there's pending DML
    – Al Cher
    Mar 20 at 9:39
  • @AlCher I don't think it's related to the data locking. Because the action works under the system admin profile, public sharing model or when a current user is the owner of the record. Mar 20 at 9:45


Your Answer

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