Yes, both cloud and/or on-premise backup storage options are offered. We have the ONLY product that offers both on-premise and Cloud deployment for backup and recovery. There is no surcharge for Cloud storage.

For the transport of data between SFDC and storage location, the Salesforce Partner API uses SSL and is approved by We are a certified product, and have been since 2005. There are many DBMS’s that offer SSL SQL connections.

For data at rest, if you chose the on-premise deployment, the database security is up to you. In our Cloud offering, the back end database is the encrypted Enterprise version of SQL Server on a server with no public access in an IBM data center. You do not have any access to even your own data in our Cloud offering.

As far as the auditability of security, if you use the on-premise deployment, you own the security. You can lock down your server so you have to log in to the server to access even the web user interface. If you use our Cloud deployment option, you have no access to anything. Recovery is done via a webinar in consultative mode where our professional services team does the actual recovery.

Archive is defined as the ability to backup and maintain data in a non-SFDC storage location and automated deletion of data from SFDC on a specific retention schedule.  The backup archive of the data would always be maintained outside SFDC based on a separate retention schedule.

RJ handles both use cases. You can set flags in the database and use the product to archive massive amounts of data safely, knowing that you can always recover it. The versioning is on a record level, with a primary backup table for the current image and a secondary table for the prior versions of each record. This gives you lower space utilization, frequent incremental backup of just the changed data, and the ability to see all prior versions of a record. Great audit trail too.

Yes. The only thing you’ll have to do is provide the URL of the Sandbox instance in the configuration. Product pricing is based on Production Salesforce orgs, so this is not even a factor.

No, not the way you’re thinking. Metadata can only be corrupted by a System Administrator, not end users, so there are very few cases in which this would have any value. However, if you were to delete a field or an object, you absolutely could get it back entirely, although you’d have to create the object and fields in the configuration screens before you copied the data back to Salesforce. We never delete data, even if you drop the field from Salesforce.

Relational Junction for Salesforce backs up and will restore typically any Salesforce object that is allowed by the Salesforce API and security rules. You cannot create certain objects in Salesforce, such as AccountHistory, because it’s just not allowed by the Salesforce application. There are no issues with handling binary data, such as Attachments an Documents and ContentVersion.

It would be easier to tell you what Relational Junction for Salesforce doesn’t copy. This is a list of current objects that cannot be backed up because they are not “real” objects or have specific technical limitations of the API in copying records without some sort of specific qualifier.


The Cloud deployment option — where Sesame manages the service in our Cloud — offers no data access to you for reporting. This would be a security concern, as well as causing performance degradation in our multi-tenant environments.

The on-premise deployment option gives you a relational database with indexed relationship fields for all table joins. You can use any Business Intelligence or reporting product. You can run this on your on-premise servers, Amazon AWS, or anywhere.

Yes, but you actually have to specify what it is that you want to restore by setting a control field on at least the top level of the relational hierarchy, such as the Account, which will recover that Account and all its Contacts, Opportunities, etc. You can recover any record to any point in time using the secondary backup table that contains all the prior versions of every record. You can be selective about what fields you want to recover. There is no option to push a single button and recover everything because that is an implausible use case in practice. is not a Master File that you would restore to yesterday, it is a living database of changing data from many people that would be very unhappy if you restored the entire dataset back to a point in time.

Yes, Windows Scheduler or UNIX cron or any other job scheduler is normally used to initiate replication or integration jobs. The web client is used to set up and test the job, but is not for normal production job scheduling. The command line interface is very easy to run from any scheduling system.