So I'm using the XL-Connector add-on to insert some 30k records into the database. The records are inserted in batches of 200. Based on some complex logic in the insert trigger, I'm determining if some extra records of the same type need to be upserted(these are forecasts for other months of the fiscal year, created based on the data found in the batch). The problem is that, if in the 200 records batch that ran an error occurs for some records, the upsert for the successful records is being rolled back. As an example, if I run the batch and out of 200 records, 99 fail, the 101 records are inserted successfully in the database, however the 50 forecasted values that need to be created in the record trigger on the after insert event are upserted successfully and then rolled back.

Any idea how to overcome this issue?

1 Answer 1


It is a bit tricky without knowing the exact logic that your after insert trigger is running, but from your original post it seems that the connector is using Salesforce's Bulk API to perform the DML operation.

When you say that "101 out of 200 records are inserted successfully" do you really mean that you checked your Salesforce instance and see that the data for the 101 records is upserted? It could be that what you are seeing in your logs is just "101 records update without error" for that batch of records, but in reality Salesforce rolls back the entire batch in case of errors.

What you could do to overcome this is to set up your Excel add-on to 1) perform one update per row (it could take a lot of time and consume a lot of your daily API calls depending on the number of records, so please check those before trying this) or 2) analyze and fix your data beforehand so when you do upsert it you won't get those errors. That way there's no reason for the transactions within each batch to fail, and your changes won't be rolled back.

  • Hello, Yes I have queried the 101 successful records and also checked them on the interface, and they are all there. Also in the debug logs I see the Ids of the 50 forecasted values that are rolled back but when I try to access any of those records by id in the interface I get the error related to The requested resource does not exist Commented Jan 4 at 9:39
  • Also related to the proposed solutions. 1) This is not optimal at all because of the way the forcasting logic works. If, let's say, I insert only data for 5 months of the fiscal year, the trigger should create 7 more records until the end of the fiscal year which are flagged as forecasts. If I insert the records 1 by one it will be a bit overkill for the trigger. 2) While some data can be clearly distinguished as bad data beforehand and fixed prior to deploying there are some rows that don't have this indicator at all. These are the rows that cause problems Commented Jan 4 at 9:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .