Yes. The relationship fields are stored in the database. When records are restored, the relationship fields are updated for all the child records as the parent records get new Salesforce ID’s. This is a patented process that allows one-pass restore of related data, including recursive relationships.

Contact.AccountID –> Account.ID

Contact.ReportsToID — Contact.ID

Even multi-level relationships are supported (Account1 has Contact1 as its child, which has Account2 as its child in a custom relationship).

There is no limit. We have customers with terabytes of data.

Relational Junction uses patented and patent-pending technology to limit queries to manageable sizes, preventing fatal timeouts and staying within limits of the Salesforce API. Performance of the product is an order of magnitude faster than the Salesforce Bulk API and does not require intermediate landing files.

Yes. Content Version can also be backed up and restore, within reasonable limitations of your hardware to store the entire record in memory.

Yes. The only limitations are

  • The object must be “Createable” — a term which Salesforce means the Salesforce application allows an API user to create new records. For instance, AccountHistory and OpportunityHistory records are not Createable; they are created internally by Salesforce.
  • The user must have security permission to create records in Salesforce.

Yes, the product automatically adds new objects and fields, and keeps old objects and fields that are removed from Salesforce until you specifically request that they be dropped from the database. The only non-automated process is if you change data types in Salesforce, in which the database was originally a number or a date. In that case, you would get a warning message every time a job runs on that object telling you what field didn’t match. If there was every any actual data that couldn’t be copied, the job would fail and let you know that you have to make a decision to drop and re-add the column with the correct data type, using the following command:

RJ4Salesforce -config [config name] -dropColumnForce [object name] [field name]

This is not automated because you might want to preserve or even recover the old data, since Salesforce drops and re-adds the field, leading to possible loss of data.

If you turn on History Tracking, prior versions of each record are retained in a secondary table. You can purge the history with a SQL DELETE or a TRUNCATE statement for the secondary backup tables. There are no versions of the entire dataset, since we’re using a single database schema with secondary backup History Tracking tables to keep prior images of individual records.

All data is retained forever. All versions, if you turn this feature on, are retained unless you physically delete them from the database. The prior versions are in separate tables, so you can manage space more easily.

You can create multiple databases for different purposes, and they will be updated when their own replication cycles happen under your control. But instead of versioning the entire set of data for a single org, you can keep prior versions of individual records in a secondary table for each Salesforce object. This is not Salesforce’s History object, it is our own feature. There is a primary table for each object, and a secondary table that contains each prior snapshot of that record. This approach conserves the amount of database space required to store all versions, and fits better into the incremental replication process.

Yes. This is all done through your own scheduling system or Windows Scheduler, or cron if using UNIX.