What options the SFDMU has to perform a pre-validation before data insert?

Question.

When using SFDMU, it works in a partial success way, where the valid records are inserted even if other records fail.

In customer scenarios, this is not always the desired way, as there is the risk of leaving one Org in an unfinished status regarding data (some records inserted but some others not).

Because of that, for those scenarios, validation of data or data rollback is a frequently asked feature.

When using SFDMU, this could be done by using the simulationMode feature, however, I found that it only detects missing parent records (both types lookup and master-detail) and 'MissingParentRecordsReport.csv' file is created. It doesn't validate records against e.g. validation rule or uniqueness of fields.

I would like to know, which options SFDMU has in order to perform a pre-validation ?

Answer.

Since record rollback is not fully implemented by the SF, so you have two options to perform a pre-validation with the SFDMU:

• As you mentioned, you can turn the Plugin into the simulation mode by setting the simulationMode=true.

  This will give you an indication, which records are fetched from the Source and which are about to be pushed to the Target.

  From another side, in the simulation mode the records in target org are not actually updated (as already said, we have to leave them untouched because there is no records rollback feature in the Salesforce API), you can't use the simulation mode to test your update against target triggers, validation rules and other functions which require actual update of records.

• The second option is to set allOrNone=true for sObject which records you want to rollback in case of failure.

  This will activate the OOTB all-or-none feature implemented by the Salesforce API. The problem is that this feature supported only by the SF REST API but the SF Bulk API has no rollback options at all.

  In the SFDMU you should set also the alwaysUseRestApiToUpdateRecords=true, which forces using the SF REST API instead of SF Bulk API for all transaction of the current job.

  Be aware, that the REST API typically spends more resources and quotas than the Bulk API and sometimes you can run into the limitation issues.

  This method will rollback all records modified only by the current unsuccessful transaction, but other transactions which have already successfully completed will still be committed.