Salesforce to Salesforce Integration: Implementation Guide

In this article, you will learn why a Salesforce to Salesforce integration may be necessary in specific circumstances, and how to set one up using a number of common methods. You’ll also learn how to follow some best practices when it comes to working with a Salesforce to Salesforce integration.

Table of contents

  1. What Is Salesforce to Salesforce Integration?
  2. Why Do We Need Salesforce to Salesforce Connection?
  3. Salesforce to Salesforce Connector Using the Standard Connector
  4. Salesforce to Salesforce Integration Using REST API
  5. Salesforce to Salesforce Integration Using Skyvia (No-code appoach)
  6. Salesforce to Salesforce Data Integration Best Practices
  7. Summary

What Is Salesforce to Salesforce Integration?

Salesforce to Salesforce integration is something that a select few Salesforce customers may ever need to consider. Depending on the business requirements, some businesses may need multiple Salesforce orgs within a single business, while others may need to simply share records with partners that they work with.

Why Do We Need Salesforce to Salesforce Connection?

If your business has multiple Salesforce orgs for different purposes, or you are partnered closely together with another business that uses Salesforce, then you may need to share/collaborate on records across multiple orgs. Creating a Salesforce to Salesforce connection will allow you to set up the connection between the two orgs and share records between them.

Imagine you’re working for a small business who are acquired, and rather than immediately merging the two orgs they’ve decided to run them side by side for the interim. Setting up a Salesforce to Salesforce connection will provide the flexibility to run two orgs side by side, and share records between them where necessary.

Another example would be if your business manufactures a product and you use Salesforce to keep track of how many products are being built and how many are in stock, but you outsource your selling to another company and they want the ability to collaboratively work on deals in your org. Rather than setting up a Partner Community for them (which requires standing up of an Experience Cloud Template, purchasing of licenses, and configuring permissions), you decide that the best way to work together would be to configure a Salesforce to Salesforce connection between your Salesforce org and theirs.

explore pricing

Salesforce to Salesforce Connector Using the Standard Connector

Salesforce has built their own connector that can be used to make it easy for businesses to connect and share records between multiple Salesforce orgs. Unfortunately, this functionality has not been maintained very well in recent years and as such you will need to configure this functionality within the Salesforce Classic UI, as it is not available in Lightning. For this reason, we suggest looking at some of the other options outlined in this article for Salesforce to Salesforce Integration.

Configuring Salesforce to Salesforce Integration Using the Standard Connector

As mentioned above, you will need to ensure you have switched to the Salesforce Classic UI to configure the Standard Connector.

Ultimately, there are 4 key areas that need to be configured when using the Standard Salesforce to Salesforce Connector:

  1. Turning the Salesforce to Salesforce Connector On
  2. Creating the Salesforce to Salesforce Connection
  3. Publishing Relevant Objects and Fields
  4. Subscribing to Relevant Objects and Fields

To read more about the guidelines and considerations when using the Standard Connector, please feel free to give Salesforce’s official documentation a read, otherwise you can read a subset of the key considerations below.


After switching over to the Salesforce Classic User Interface, head over to Setup. Search ‘Salesforce to Salesforce’ in Quick Find in Setup, and click Salesforce to Salesforce Settings. Once you have enabled the feature, you should see a screen like the one below.

Salesforce to Salesforce Setup

Once you’ve enabled it in the first org, you need to repeat the process in your second org before you can start sharing data between them.


Now that both your orgs (We’ll refer to them as Org 1 and Org 2) have had the Salesforce to Salesforce feature enabled, it’s time to build a connection between them. The process here is not what you’d expect – you need to create a Contact record, and send them an invite through a new Connection record.

Create your Contact record with a valid Email Address – this is where you will send the Connection Invite to. Once you’ve created your Contact record, go to the Connections tab and click New Connection. Ensure you’ve set the new Contact record as the Contact, and also set the relevant Connection Owner on your end. Then click Save & Send Invite.

Creating Salesforce to Salesforce connection

Receive the email on the other side, and set up the Connection record in Org 2. Congratulations, you’ve built your Connection between your two Salesforce orgs! The next step is to configure what data should be sent between the two of them.


This step will need to be performed in both Org 1 and Org 2. Click on your new Connection record that you’ve just created and navigate to the Published Objects Related List. This is where you’ll be able to select Objects that you want to send to the other org.

In this example, we are going to sync the Account records between orgs. To do so, check the Account object in the next page and click Save.

Salesforce org to Salesforce org integration: add or remove published objects

Now you need to select the fields that you want to send between orgs. In the Published Objects Related List, click Edit next to the Account row. Note that the Required Fields (Account Name and Last Name in this case, because I have Person Accounts enabled in this org) are automatically enabled and cannot be undone. You can optionally add other fields to be published to the other org.

In this case, we’re going to keep things simple and leave the default values selected and click Save.

Salesforce org to Salesforce org integration: edit published fields

Remember to repeat this in both orgs to ensure a two way data flow.


The last thing you need to do is to subscribe to the published fields – once again, this should be done in both orgs.

Navigate one last time to the Connection record you created in Step 2 and click Subscribe/Unsubscribe on the Subscribed Objects Related List. Similar to the above, check the box next to any object you want to subscribe to and click Save (in this case, the Account Object).

Finally, click Edit next to the Account row and make sure the fields you want to pull in are selected (once again, the required fields should be populated by default).

Salesforce to Salesforce Standard Connector Considerations

There’s a few things you need to know about the standard Connector in Salesforce.

  1. While System Administrators can opt to share all records, a majority of users will only be able to forward/share records that they or their subordinates have ownership over.
  2. The Salesforce to Salesforce connector only works in Salesforce Classic. This is usually not a great sign for a feature as it’s been quite a number of years since Salesforce Lightning came out, and a lot of the features that were never migrated were completely replaced.
  3. You need to pay special attention to make sure that hierarchical sharing doesn’t have a negative impact on your sync. There are a number of considerations when it comes to hierarchical privacy, but a few key ones are as follows:
    • To stop sharing a record, you need to click the Stop Sharing button in the External Sharing Related List.
    • To stop sharing Case Comments or Attachments, you must make the records Private.
    • Related records are no longer shared with a connection if the related record is edited from an unshared record.
  4. A maximum of 100 Tasks per related record can be shared, which includes both Open and Closed Tasks.
  5. Update records are processed asynchronously, so there may sometimes be a small delay in record changes appearing across orgs.

Salesforce to Salesforce Integration Using REST API

There are other alternatives to share data between multiple Salesforce orgs if you’re not a fan of the included Salesforce to Salesforce tool. You can use Salesforce’s REST API to build a connection between two orgs (or other sources) and transfer data between them.

This method will require you to have developer resources on hand (whether they’re internal, or you hire some externally) and comes at a significantly higher cost when compared to other methods. That being said, you have the flexibility to do a lot more as you’d have full control over what data is being sent and received, when it should be transferred, any additional filters on the data that you need, etc. so it’s not all doom and gloom here!

The biggest benefit to going down the API route is the ongoing cost. I mentioned above that the setup cost of such an integration is significantly higher, as you’ll be developing it completely from scratch, however once you’ve set it up and your well-oiled API machine is functioning as expected, your costs essentially cease at this point. You don’t have a middleware system to pay for, and assuming there are no issues with the integration (which is hopeful, as these things usually do break throughout their lifetime, however infrequent). With all of that said, if you do need to enhance your integration, those high costs of development return as you will need developers to enhance the existing API integration.

Setting Up Salesforce to Salesforce Integration Using REST API

There are four key steps when setting up a Salesforce to Salesforce connecting using REST API:

  1. Building the REST API Endpoints (Org 1)
  2. Creating the Connected App (Org 2)
  3. Configuring the Auth Provider (Org 2)
  4. Creating Named Credentials (Org 2)


You’ll need to build out an Endpoint using an Apex Class before you are able to connect two Salesforce orgs using REST API. Below is an example of how to do so (Mine was called ‘SFtoSFEndpoint’) – build this out in the first org.

global with sharing class AccountAPI {
    //this section handles deletions through the API
    global static void doDelete() {
        RestRequest req = RestContext.request;
        RestResponse res = RestContext.response;
        String accountId =
        Account account = [SELECT Id FROM Account WHERE Id = :accountId];
        delete account;
    //this section handles queries through the API
    global static Account doGet() {
        RestRequest req = RestContext.request;
        RestResponse res = RestContext.response;
        String accountId =
        Account result = [SELECT Id, Name, Phone, Website FROM Account WHERE Id = :accountId];
        return result;
    //this section handles inserts through the API
    global static String doPost(String name, String phone, String website) {
        Account account = new Account();
        account.Name = name; = phone; = website;
        insert account;
        return account.Id;


Once your endpoints are configured, you need to create a Connected App within App Manager (Search ‘App Manager’ in Quick Find in the Setup Menu, then click New Connected App).

Salesforce Connected App Manager

Give your Connected App a Name and API Name (I used ‘SalesforceToSalesforce’). Set the Contact Email relevant to your contact details, then check the ‘Enabled OAuth Settings’ box, and set a callback URL (Use as a placeholder until later on in the process), and select your relevant OAuth scopes (in this case, I’ve enabled full, api, and refresh_token/offline_access). Leave the rest how it is, and click Save.


Once you’ve saved your Connected App, copy your Consumer Key and Consumer Secret – you will need these later (remember to keep your Secret a secret!).


Now from your other org you need to create a new Auth Provider (Search ‘Auth. Provider’ in Quick Find in Setup). Click New to create a new Auth Provider, and select Salesforce as the Provider Type.

This will display the full form for you to populate. The key fields you need to populate are as follows:

  • Provider Type = Salesforce
  • Name = I used ‘SalesforceToSalesforce’ in this example
  • URL Suffix = I used ‘SalesforceToSalesforce’ in this example
  • Consumer Key = Paste your key from the last step
  • Authorize Endpoint URL = Leave blank, Salesforce will automatically set this
  • Token Endpoint URL = Leave blank, Salesforce will automatically set this

Then click Save to save it.

Auth. provider edit in Salesforce

At this point, you will have a new Callback URL generated at the bottom of the page in the ‘Salesforce Configuration’ section. Copy this Callback URL and update your Callback URL value in the Connected App you created in the above step.

Salesforce Callback URL generated

At this point you can check your connection between the two orgs and test that it is working as expected so far. Use the ‘Test-Only Initialization URL’ to make sure that everything is working as expected. If you don’t see a login screen when you navigate to the Test-Only URL, you should double check that your Callback URL was updated in the Connected App and you have waited 2–10 minutes for the changes to take effect.


Finally, you need to create a Named Credential so that the org that is making the callouts can connect to the org with the Connected App with ease. To do this, search for ‘Named Credentials’ in Quick Find in Setup and click New.

The key values you need to populate are as follows:

  • Give your Named Credentials a Label and Name (I used ‘IntegrationUser’)
  • URL: Set your URL according to your own Salesforce org (The same one you used in the Connected App)
  • Identity Type: Named Principal
  • Authentication Protocol: OAuth 2.0
  • Authentication Provider: Set this to the Auth. Provider you configured in the previous step
  • Scope: ‘full refresh_token’ (remember, additional scope items must be separated by a space and you can only use the same scopes that you set in the Auth Provider)
  • Allow Merge Fields in HTTP Header: TRUE
  • Leave everything else the way it is by default, and click Save.


Finally, you can create a new Apex class in your Org 2 and make sure that everything is working as expected. Here’s a sample Apex Class, and a few lines of anonymous Apex, that you can use to make sure everything is functioning as expected.


public with sharing class AccountWebService {
    public static Http http = new Http();
    public static HTTPResponse response;
    public static HttpRequest request;
public class NewAccountRequestWrapper {
    public String name {get; set;}
    public String phone {get; set;}
//test querying an Account record
public static void getAccount(Id accId) {
    request = new HttpRequest();
request.setEndpoint('callout:SalesforceAccount/services/apexrest/Account/' + accId);
    response = http.send(request);
//test creating an Account record
public static void addAccount(NewAccountRequestWrapper newAccount) {
    request = new HttpRequest();
    response = http.send(request);
//test deleting an Account recoord
public static void deleteAccount(Id accId) {
    request = new HttpRequest();
request.setEndpoint('callout:SalesforceAccount/services/apexrest/Account/' + accId);
    response = http.send(request);


//Add a new Account
AccountWebService.NewAccountRequestWrapper newAccount = new AccountWebService.NewAccountRequestWrapper(); = 'Test Account'; = '61412345678';
//get Account details based on Id
//delete Account based on Id

Salesforce to Salesforce Integration Using Skyvia

There’s one method that you can use to not only build a Salesforce to Salesforce connection, but also infuse your Salesforce data with data from other sources, or backup or synchronize your Salesforce data, and that’s with Skyvia.

Skyvia’s Salesforce connector is one of many other connectors that you can use to build complex data integrations and connections between multiple sources, including a scenario where you have more than one Salesforce org that you’d like to share data between.

If the scenario you are working with is that your business has been acquired or has acquired another business, you may need to connect your Salesforce org to another CRM system that isn’t Salesforce. Luckily, this is something that Skyvia supports quite easily, and can be added on if you already have an existing Salesforce to Salesforce connection set up through Skyvia. Some of the other popular integration scenarios between Salesforce and other CRM Systems on Skyvia are:

  • Synchronize Zoho CRM and Salesforce data
  • Synchronize SugarCRM and Salesforce data
  • Synchronize Dynamics CRM and Salesforce data
Skyvia connectors select page

Configuring a Salesforce to Salesforce Connection Using Skyvia

To create a Salesforce to Salesforce connection on Skyvia, you will need to first authorize and correctly set up an integration with one Salesforce org. Test this connection thoroughly and make sure everything is configured correctly before adding the second one to ensure there are no nasty surprises.


Navigate to Skyvia and click New, then Connection. Find the Salesforce Connector from the list, and configure your org details. Make sure to use OAuth 2.0 and click the Sign In with Salesforce. Remember which credentials you use with each authentication, and name the Skyvia Connection accordingly (in this example below, I’ve called mine ‘Salesforce Production MASTER’). We are going to sync its data to another Salesforce org.


Repeat this for the other Salesforce org (and in the future you can also connect to any other org you’d like as well, which may or may not be a Salesforce org – Skyvia has many connectors for different apps, and many features for synching data between multiple sources).


Once you have created a Connection for each org you want to sync, you need to create an Import job between them. Click New at the top of the Skyvia app, and then click Import.

You’ll see a page where you’re able to specify source and target settings. Under Source, click Data Source database or cloud app. Then select the two Salesforce Org Connections that you created in Step 1.


Once you’ve selected the two orgs you’re wanting to synchronize data between, you need to create a Task – you can click the Add New button on the right-hand-side of the page to do so.

Select the Account object and then Next Step. On the next page, also select the Account object. We also select the UPSERT operation in order to avoid creating duplicates. We will use the native Salesforce External Id method for this operation and select the corresponding External Id field.


On the next page, also select the Account object and then click Next Step again. On the third page, you’ve got the opportunity to configure how the fields from each side should align. This is going to be different for everyone, but for our example you need to make sure that you’ve cleared the mapping and realigned the Name columns are aligned, as per the screenshot below. You also need to map the selected external ID field to the corresponding field.


This means that the Skyvia system is going to sync your Account records (and specifically, the Account Name field on the Account records).

Validate your Job by clicking the Validate button. If you’ve done everything correctly, you should see a popup saying as below, confirming that your import job is constructed properly.

Once validated, click Save to save your Job. You can also click Run Now to perform the first sync manually.


To allow your Synchronization to occur automatically in the background, you need to create a schedule for the Import Package to run automatically on. This can be found at the top-left of the Import page you’ve just created in Step 2.


Depending on the complexity of your Import Package, your business rules, and your business requirements, you will need to configure the Schedule yourself. That being said, it’s not overly complicated. As you can see in the screenshot below, I have set up a Schedule to run every 15 minutes, starting now. Configure this page according to your own needs.

scheduling the two salesforce orgs sync in Skyvia

If you don’t want to load all the records each time, but sync only new and changed records, edit the job, edit its task(s) and select the Updated button on the first page of the editor.

Skyvia package task editor 2

Considerations When Integrating Salesforce to Salesforce Using Skyvia

You may notice that setting up a connection through Skyvia is significantly easier than the other options, and far more flexible. This is the way that Skyvia has been designed – it’s as simple as creating a connection, creating a package, scheduling automatic package execution.

What is also important to know is that among other things Skyvia also allows mass updating records in Salesforce, which can be of help when you need to quickly update large data volumes and do it quickly and easily with minimum efforts.

Salesforce data archiving is also possible with Skyvia. For this, one can use Skyvia Data Replication to retain a full replica of Salesforce data as a data archive.

Remember to always keep a backup of your data, and create a contingency plan for any errors you may come across. You can also use Skyvia for this backup, as I’ve mentioned before in a previous article.

This example uses import package for syncing data in one direction. However, Skyvia also has tools for bi-directional synchronization too — synchronization packages.

Why Skyvia May Be Your Best Option for Salesforce to Salesforce Integration

I’m obviously biased when I write this, but I believe that there’s a high chance Skyvia is the best choice for your business when it comes to cost, practicality, and flexibility of your Salesforce to Salesforce integration.

Considering what can be done with the built-in connectors, Skyvia offers more than just Salesforce-to-Salesforce integration within a majority of their pricing plans. You can connect to a data warehouse, more than 2 Salesforce orgs, other CRM systems, other business systems, etc. Each connector you configure simply allows you to expand your data connectivity across Skyvia, enriching your Salesforce data more and more each time.

Skyvia is also much easier to set up than the alternatives (ESPECIALLY when considering the flexibility of the REST API vs Skyvia, and the amount of effort required to set both up). Using clicks, not code, Skyvia has similar flexibility to what can otherwise only be achieved through an API integration.

Salesforce to Salesforce Data Integration Best Practices

It’s important to plan out your Salesforce to Salesforce integration before connecting the orgs together. Here’s a few key things you need to take into account.

The advice below aligns quite nicely with our previous article, Salesforce Data Migration Best Practices. Feel free to have a more detailed read of that.

Define Object and Record Scope

Make sure to make a definitive plan as to the exact scope of the integration. If only a subset of data is being synced between Salesforce orgs, or only a single team’s data will be impacted, this will need to be communicated and planned for accordingly.

Similarly, larger Salesforce-to-Salesforce integrations can take a lot of time and effort – especially when cleansing larger data sets, or merging data from multiple origins and ensuring no duplicate records are created. Keeping a Salesforce-to-Salesforce integration project within a set budget is important, and this budget should be defined from the outset.

Tidy Your Data

Plan for where your data is going, not where it’s coming from – clean it before setting up a sync to your other Salesforce environment. Ensuring your data is clean, tidy, and the data models of your two orgs are aligned before it is synced means your Salesforce data integrity remains intact across both orgs and your users are still able to gain value from your data.

Create Integration Plan

There’s no point setting up a Salesforce-to-Salesforce integration and spending time and effort preparing for it and setting it up if it’s going to fall apart shortly after kickoff. It’s critical to create an integration plan to ensure that the data is validated and sync errors are resolved so as to continue providing value to your business users.

The integration plan should detail how data should be organized and structured in both orgs going forward. Things like which data should be kept in which environment, how data should be validated before being stored in either org, who is responsible for data validation, etc. These things should all form part of the integration plan.

Create Contingency Plan

There’s a high chance you will run into some kind of roadblock while setting up your Salesforce-to-Salesforce integration. This will likely be due to data not being organised properly, or data not being formatted correctly, or a Validation Rule being hit inside of one of your Salesforce orgs. Salesforce Best Practice is to record the error that you receive. This way, you can continue along your original integration plan as much as possible and tidy up any leftover data at the end, rather than getting stuck at a single point.


When your business has a requirement to connect two Salesforce orgs together, for any reason, you need to carefully consider exactly why it is required, what data is required to be synced between them, the frequency in which it needs to be synced, and carefully craft a plan (and contingency plan) so that you’re not met with any nasty surprises while setting up the connection.

If you decide to use Skyvia Data Integration to connect your Salesforce orgs together, you can leverage multiple other features like data backup, data replication, and integration with other third-party data services.

To learn more about Skyvia Data Integration, click here.

discover our pricing
Tim Combridge
Tim Combridge
Salesforce Solutions Engineer



Skyvia podcast