Salesforce Reference

Salesforce database schema

Your Sequin database will contain tables for each of the following Salesforce objects:

• Account
• Contact
• Lead
• Opportunity
• User

We will also sync any custom objects you may have.

Need additional objects in your sync? Just send us a note!

The syncing process

By default, we limit our sync to one request every three seconds. This means about 20 request per minute or 29,000 requests per day. We use these limits to stay well below your daily API quota. If this isn't the right rate limit for you, send us a note.

We first backfill your database with all your Salesforce data. We're able to pull 200 records per request. This means, by default, we can process just over 200,000 records per hour. So, if your Salesforce instance contains millions of records, the backfill can take a while. We'll email you when your backfill is complete and all your data is loaded into your database.

After the initial backfill, we'll continuously poll your Salesforce instance to monitor changes. Respecting the rate limit, we'll round-robin each of the tables you've selected to sync. We're able to handle up to 200 creates and updates across your tables every three seconds. So if you're syncing five tables, we'll be able to process up to 1,000 creates and updates between those five tables every 15 seconds.

Writes

When you make changes to rows in your Salesforce tables, Sequin writes those changes back to Salesforce. Translating creates, updates, and deletes in your database to Salesforce API requests is handled for you by Sequin.

Like syncs from Salesforce to your database, writes from your database to Salesforce respect the API quota you've specified. Both processes share the same quota. To more efficiently manage your quota, you can configure batching for your writes. With batching enabled, you can tell Sequin to wait for a batch of X size for up to Y seconds.

Errors

Debugging

For debugging purposes, you can see the queue of changes that have been written and will be written to Salesforce in the table _sync_write_log. Each row in this table maps to a change you made to a record in your Salesforce tables. For example, if you deleted 10 records, you would have 10 entries in _sync_wite_log, one for each record deletion. If you inserted then modified a record, you'd see a _sync_write_log row for the insert and another row for the update.

The key columns in _sync_write_log:

table_name, action, and api_id

The combination of these columns will help identify which change a given _sync_write_log row pertains to. action is an enumerable, one of insert, update, or delete.

state

Indicates the state of this change. state is enumerable of one of the following values:

• new: this change was recently made in your database. A Sequin worker has yet to attempt to write this change back to Salesforce.
• pending: A Sequin worker is currently processing this change. If you don't have batching enabled, this write is currently being sent to Salesforce. If you have batching enabled, this write may be part of a batch that's waiting for more writes before being sent to Salesforce.
• succeeded: A Sequin worker has written this change to Salesforce.
• failed: A Sequin worker attempted to write this change to Salesforce but failed. See the column api_result and api_message for the status code and response message from Salesforce.

old

This column is a jsonb representation of the row before the change took place.

values

When a row is updated, values is a jsonb representation of the changes made to the row. These values are used to create the PATCH request that Sequin sends to Salesforce.

api_result and api_message

The combination of these columns indicate the API's response code and message to Sequin's write request.

Salesforce returns a 201 status code for successful inserts, a 204 for successful deletes, and a 200 for successful updates.

If the write failed, you'll usually see a non-2XX status code. The api_message can help identify what went wrong. Sequin is proactive about surfacing and helping resolve failed writes back to APIs. If you need help with an API failure and haven't heard from us already, please reach out.

Security

Your Sequin database will contain all your Salesforce data - which includes PII and sensitive information. We take the security of that data seriously.

Please read about our full security practices. Here is a short synopsis of how we keep your Salesforce data secure:

• You supply us with an API key which is encrypted at rest. The Sequin application database is only accessible through a bastion host.
• We only access customer databases by request or to diagnose a sync issue.
• Sequin workers first backfill your database with all your Salesforce data. During this backfill, Sequin will receive events as they happen to keep your data in-sync.
• Data flows directly from Salesforce, through Sequin workers, to your database. We don't cache or store Salesforce data anywhere else.
• We use Sentry and Datadog for error monitoring. Sometimes errors Datadog catches will contain API response data. But these are minimized and our logs in Datadog have a shelf-life of 30 days.
• By default, Sequin provisions a private database and a database user for you on a shared RDS instance. While Sequin shared instances are secure, we can also sync to a database you own for greater peace of mind.