This version of Salesforce reached end of life on December 18, 2017 and is no longer functioning.
Salesforce integration summary
Salesforce feature snapshot
A high-level look at Stitch's Salesforce (v15-10-2015) integration, including release status, useful links, and the features supported in Stitch.
Sunset on December 18, 2017
|Singer GitHub repository
|Configurable Replication Methods
Replication Key Selection
While Stitch generally uses Incremental Replication to replicate data from Salesforce, the Replication Key used to identify new and updated data may vary from object to object.
Stitch’s Salesforce integration dynamically selects a column to use as the Replication Key based on the columns that are available in the object. This means that Stitch will loop over the fields below, in order, and select the first one found to use as the Replication Key:
If none of these fields are found, the object will be replicated using Full Table Replication.
The exception to this is the
LoginHistory table, where Stitch will check for the fields listed above and the
Note: Data in formula fields may become “stale” as a result of Stitch’s replication approach and how these fields are updated in Salesforce. Refer to the Stale Salesforce Data & Formula Fields guide for info on preventing discrepancies.
Sync Time & API Quota
Usage of Salesforce’s API is determined by how much API quota you have. An API quota refers to the total number of API requests that can be made in a given period of time.
Due to the volume of data and the daily API quotas imposed by Salesforce, an initial sync of your Salesforce data can take awhile.
- If a single replication attempt uses 20% of your daily quota, replication will stop.
- If more than 80% of your daily quota has been used - this includes usage from Stitch as well as any other apps you may be using - replication will stop and resume once more is available.
Continually hitting these limits can cause an initial sync to take several days. Check out this Salesforce article for more info on calculating and increasing your total API calls.
Salesforce table reference
Schemas and versioning
Schemas and naming conventions can change from version to version, so we recommend verifying your integration’s version before continuing.
The schema and info displayed below is for version 15-10-2015 of this integration.
In Salesforce’s API, “object” is synonymous with “table.” When Stitch replicates data from a Salesforce object, a table for that object will be created in your data warehouse. The “fields” contained in an object are the same as columns in a database table.
Note: Tables won’t automatically be created in your data warehouse. You must set tables and columns to sync in the Integration Details page first.
Stitch will replicate the majority of Salesforce objects (with the exception of those listed here). To ensure we can provide you with up-to-date docs, we won’t dive into the specifics of the hundreds of Salesforce objects Stitch can replicate.
Objects Stitch Replicates
Below you’ll find the objects and fields Stitch can replicate, a brief description, and how different table and column types will be named in your data warehouse.
Standard objects are those that are created by Salesforce and included in your account by default.
Custom objects are tables created by you that enable you to store info unique to your organization. Refer to the Custom Objects section in the Object Reference guide for more info.
Fields are attributes that describe an object. A Standard field is created by Salesforce.
A Custom field is a field created by you. Refer to the Custom Fields section in the Object Reference guide for more info.
Objects Stitch Doesn't Replicate
Stitch will not replicate:
- Objects that the authorizing user doesn’t have permission to access, and
- External objects (which are objects created by you to map to data stored outside of your organization).
Object/Field Names & Collision Errors
In Salesforce, it’s possible to have objects and fields with names that use both upper and lower case. For example:
If the uniqueness of the field name is only in the case - meaning that the only difference between them is upper and lower case characters - you may encounter field collision errors if:
- The data warehouse you’re using is case insensitive AND doesn’t maintain case, and
- There’s more than one field in the table with the same name
You can check out the Destination Comparison Rollup for more info on how your data warehouse implements case sensitivity.
orders table contains two columns:
salesorder. These columns are different only in that one has an upper-case
O and one has a lower-case
If the data warehouse doesn’t maintain the case, these field names will canonicalize - or be converted - into the same name. Because Stitch won’t know where to insert the data if both field names are the same, this will result in a
field collision error.
You can resolve this error by changing the name of the field in Salesforce to something unique.