why are my records failing salesforce upload

Merely like most relational database systems, Salesforce locks records when they are beingness modified, to prevent two people from updating the aforementioned record simultaneously, which would upshot in a disharmonize. And so when someone "asks" Salesforce to update a record, Salesforce first locks the record and then no one else can update information technology until the lock is released. If someone tries to (asks for an) update the record while it'south locked, Salesforce volition try upward to 10 times to obtain a record lock, earlier giving upwards, and throwing an fault.

Record locking errors is a common source of headache for people coding Data Migrations or Integrations with Salesforce. The good news is that most of the fourth dimension Information technology's our own integration code that is causing cocky-contention as opposed to some other user locking the record on us (because nosotros are plowing too many conflicting updates at once, ordinarily in an attempt to ameliorate performance). It tin can too be caused by Salesforce lawmaking that is triggered by our updates that require the locks, and then, when not getting them, ultimately fail. Then, that error bubbling upward and our updates fail.

Permit's walk through an example:

Suppose we desire to update 10,000 contacts in Salesforce. We configure our ETL to push the updates in batches of 200, serially, using the SOAP API. Per batch, Salesforce will do the post-obit:

1. Lock the 200 contacts (in the batch).
2. Lock the parent accounts of those contacts.
3. Build a set of transactions to process, limiting the number of times information technology needs to lock the aforementioned record. Then, in our case, it would group the contacts by those that share the same parent account and then process them as a single transaction. With a unmarried update to the parent account.
4. If Salesforce can't obtain a lock on the parent account record, the whole transaction fails and an error is issued for each contact in the transaction.
5. If Salesforce tin can lock the parent account, but non for one of the contacts in the transaction, the update fails for that one contact simply.

Continuing with the same example, again suppose we want to send 10,000 contact records for update, and our ETL tool will break our x,000-row dataset into batches of 200 records each, based on the order of the records in the dataset. If nosotros don't order our data, we increase the number of locks taken, and with information technology the potential for record locking issues.

This next case demonstrates why.

What would happen if nosotros decide to transport our ten,000-record dataset using the Majority API, unordered, and set information technology to procedure batches in parallel. Salesforce takes those 10,000 records, breaks them upward into batches of 200 (server side), and processes them five batches at a time (in parallel).

Let's say we accept iv contacts that vest to the same parent account in the dataset. Considering they are unordered, the four contacts each land in a different batch, and considering nosotros are running things in parallel, Salesforce tries to lock the parent account four times at once, by iv different processes. None can get the lock, and all four neglect, or one gets the lock and the other 3 fail, or all pass simply afterwards wasting time on retry cycles slowing our load down considerably.

What tin we do well-nigh this? The easiest thing to exercise is to switch to serial processing, so merely one batch is processed at a fourth dimension, but that affects operation negatively (and in a serious mode) , so nosotros don't want to do that. Our other option is to sort the contacts by parent account. In this manner, all the contacts that vest to the same business relationship accept a high likelihood of being in the same batch, reducing the lock potential.

To exist articulate, I'm not saying that if we don't club our data nosotros will e'er become a locking upshot. (Call back, Salesforce tries to gets the lock upwardly to ten times, and may become it.) I'm just maxim it increases the likelihood of information technology happening. I'm likewise maxim that locking is a time-intensive process, and the retries are time intensive; so, even if we become no errors, an ordered load volition perform better than an unordered one. Even if we go no locking conflicts and Salesforce tin lock the account tape every fourth dimension it needs to, in our example the unordered list will lock the business relationship tape four times, merely our ordered load volition most likely take just one lock—two, at a maximum. (Nearly probable, all four contacts will be in the same batch, only if they happen to be right at the end of the batch, some tin spill over into the next.)

Junction Objects – Objects with 2 or more parents

If we accept a junction object, it has 2 parents, and we can merely sort by ane! So, what do we do? In that location's non much nosotros can practise, except to sort past the one most likely to cause locking bug based on our cognition of what custom Salesforce code will run when pushing the updates. Barring that, as a general guideline, nosotros can do the post-obit:

Sort by Chief-Item fields before lookups.

For lookups, sort required lookups earlier nonrequired ones.

For nonrequired lookups, sort ones set to "Don't allow deletion of the lookup record that'due south part of a lookup relationship" before ones set to "Clear the value of this field. You lot can't cull this selection if you make this field required" (meet the Epitome below).

 It's important to know that, when we select "Articulate the value of this field. Nosotros can't choose this choice if we make this field required.", updates to that record will not lock the parent. Unfortunately, this is not the default selection, so our Salesforce SA (or administrator or programmer) may have left the default option ("Don't allow deletion . . ") simply because they had no business rules or reason to change information technology. We should work with our Salesforce development squad to determine whether this setting tin can be inverse (based on the business utilise case) and, if so, modify information technology to "Clear the value of this field . . . ."

If you are still having locking issues see this article (also authored by me :-): FAQ : One bad tape is causing a batch of records to fail! How tin I prevent triggers from impacting my ETL code?

The Salesforces record locking cheat sheet can exist establish here.

This article is adjusted from my volume " Developing Data Migrations and Integrations with Salesforce: Patterns and Best Practices " (Apress December 2018)

Enjoyed this article? Visit my weblog at: http://SalesforceDataBlog.com  or subscribe by Electronic mail or RSS . Follow me on LinkedIn  and/or Twitter .

pinoboseem.blogspot.com

Source: https://www.linkedin.com/pulse/understanding-salesforce-record-locking-preventing-them-david-masri/

Share this post