Release Status Released Supported By Stitch
Availability Paid Status Page Salesforce Status Page
Default Historical Sync 1 year Default Replication Frequency 30 minutes
Whitelisting Tables and columns Destination Incompatibilities None

Connecting Salesforce

Salesforce Setup requirements

To set up Salesforce in Stitch, you need:

  • A paid Stitch plan. While those currently in the Free Trial will also be able to set up Salesforce, replication will be paused until a paid plan is selected after the trial ends.
  • To verify your Domain type. This version of Stitch’s Salesforce only supports Production domains.

  • To verify your object access. Stitch will only be able to access and replicate the objects that the user setting up the integration has access to. Before beginning, we recommend verifying that you have access to everything you want to replicate.

  • To verify your API access. To use Stitch’s Salesforce integration, your Salesforce account must have Web Service API access enabled.

    Some editions of Salesforce include Web Service API access while others don’t. Info about this feature can be found on Salesforce’s plan details page in the Connect sales info to any app section, located near the bottom of the page.

    Contact Salesforce support if you’re unsure about your Salesforce plan’s API access.

Step 1: Set Trusted IPs in Salesforce

Depending on how your Salesforce instance is set up, you may need to whitelist Stitch’s IP addresses.

The instructions in this Salesforce article will walk you through how to do this in Salesforce; below are all the Stitch IP addresses that must be added to the trusted list:

  • 52.23.137.21/32

  • 52.204.223.208/32

  • 52.204.228.32/32

  • 52.204.230.227/32

Complete this step before proceeding with the rest of the setup, or you may encounter connection issues.

Step 2: Add Salesforce as a Stitch data source

  1. Sign into your Stitch account.
  2. On the Stitch Dashboard page, click the Add Integration button.

  3. Click the Salesforce icon.

  4. Enter a name for the integration. This is the name that will display on the Stitch Dashboard for the integration; it’ll also be used to create the schema in your destination.

    For example, the name “Stitch Salesforce” would create a schema called stitch_salesforce in the destination. Note: Schema names cannot be changed after you save the integration.

Step 3: Define the Historical Sync

The Sync Historical Data setting will define the starting date for your Salesforce integration. This means that data equal to or newer than this date will be replicated to your data warehouse.

Change this setting if you want to replicate data beyond Salesforce’s default setting of 1 year. For a detailed look at historical replication jobs, check out the Syncing Historical SaaS Data guide.

Step 4: Create a replication schedule

In the Replication Frequency section, you’ll create the integration’s replication schedule. An integration’s replication schedule determines how often Stitch runs a replication job, and the time that job begins.

Stitch offers two methods of creating a replication schedule:

  • Replication Frequency: This method requires selecting the interval you want replication to run for the integration. Start times of replication jobs are based on the start time and duration of the previous job. Refer to the Replication Frequency documentation for more information and examples.
  • Anchor scheduling: Based on the Replication Frequency, or interval, you select, this method “anchors” the start times of this integration’s replication jobs to a time you select to create a predictable schedule. Anchor scheduling is a combination of the Anchor Time and Replication Frequency settings, which must both be defined to use this method. Additionally, note that:

    • A Replication Frequency of at least one hour is required to use anchor scheduling.
    • An initial replication job may not begin immediately after saving the integration, depending on the selected Replication Frequency and Anchor Time. Refer to the Anchor Scheduling documentation for more information.

To help prevent overages, consider setting the integration to replicate less frequently. See the Understanding and Reducing Your Row Usage guide for tips on reducing your usage.

Step 5: Authorize Stitch to Access Salesforce

  1. Next, you’ll be prompted to sign into your Salesforce account.
  2. A screen asking for authorization to Salesforce will display. Note that Stitch will only ever read your data.
  3. Click Allow.
  4. After the authorization process successfully completes, you’ll be redirected back to Stitch.
  5. Click All Done.

Step 6: Set tables to replicate

To complete the setup, you’ll need to select tables you want to replicate to your data warehouse.

Check out the Schema section to learn more about the available tables in Salesforce and how they replicate.

  1. In the Integration Details page, click the Tables to Replicate tab.
  2. Locate a table you want to replicate.
  3. To track a table, click the checkbox next to the table’s name. A green checkmark means the table is set to replicate.

  4. Repeat this process for all the tables you want to replicate.

Initial and historical replication jobs

After you finish setting up Salesforce, its Sync Status may show as Pending on either the Stitch Dashboard or in the Integration Details page.

For a new integration, a Pending status indicates that Stitch is in the process of scheduling the initial replication job for the integration. This may take some time to complete.

Free historical data loads

The first seven days of replication, beginning when data is first replicated, are free. Rows replicated from the new integration during this time won’t count towards your quota. Stitch offers this as a way of testing new integrations, measuring usage, and ensuring historical data volumes don’t quickly consume your quota.


Salesforce Replication

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:

  1. SystemModStamp
  2. LastModifiedDate
  3. CreatedDate

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 LoginTime field.

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 schemas

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.

Type Description Naming Convention Example
Standard Object

Standard objects are those that are created by Salesforce and included in your account by default.

sf_[object_name] sf_account
Custom Object

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.

sf_[object_name]__c sf_issue__c
Standard Field

Fields are attributes that describe an object. A Standard field is created by Salesforce.

[field_name] account_id
Custom Field

A Custom field is a field created by you. Refer to the Custom Fields section in the Object Reference guide for more info.

[field_name]__c first_notice__c

Objects Stitch Doesn't Replicate

Stitch will not replicate:

  1. Objects that the authorizing user doesn’t have permission to access, and
  2. 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: columnName

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:

  1. The data warehouse you’re using is case insensitive AND doesn’t maintain case, and
  2. 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.

Collision Example

An orders table contains two columns: salesOrder and salesorder. These columns are different only in that one has an upper-case O and one has a lower-case o.

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.



Questions? Feedback?

Did this article help? If you have questions or feedback, feel free to submit a pull request with your suggestions, open an issue on GitHub, or reach out to us.