Yes, but it would be naive to think that it doesn’t require carefully though out decisions and preparations to make so the new records fit into the target org, such as

  • Is the target org empty or does it contain existing users, products, and other slowly changing data? On professional service engagements, our team has used mapping tables to marry up the business keys in the source or with the target records by their Salesforce ID in the target org. Unique business keys are required to make this work smoothly.
  • How do you want to detect and handle duplicates? If you are merging business units, how do you determine if you have a common customer and which record “wins” in that event?

Yes. For example, for a restore operation with 5 levels deep, restore some Accounts, with their related Cases containing Tasks that include Attachments, without losing all of the different Chatter feeds. The -recover command will determine all the object relationships, maintain pointer fields in the children after creating the parent record, defer circular relationships where necessary, and finally update the circular relationships. We have multiple patents awarded and pending on this process.

You can

  • specify a small number of objects in the -set command (-set Account -set Contact -set Opportunity)
  • create a list of objects in an upload.config.[name] control file and use a -setGlobal command, referencing that particular named file
  • use a -recover command, which will recover all the children and their parent-child and recursive relationships

For any of these, you can exclude objects with an exclude.config.[name] file.

You can further exclude objects by their type (Standard, Custom, Share, Team, Tag, History).

 

Yes. There is a button you can press in the user interface that will gracefully cancel any job with full two-phase of all transactions in Salesforce and status flags in the database. This makes restores fully restartable without creating duplicates in Salesforce.

We do not create foreign key constraints because it would prevent copying records if they were done out of order, as you would get constraint violations if the child was copied before the parent. Also, some of the relationships (such as the ParentID of Attachment) point to multiple objects.