Salesforce to Salesforce Integration: Connecting Two Orgs After S2S (2026 Guide)

When you need a Salesforce to Salesforce integration

A Salesforce to Salesforce integration connects two separate Salesforce orgs so records, or views of them, move between them. It usually comes from one of four situations:

• Mergers and acquisitions. The acquired company runs its own org. Leadership wants one pipeline report next week, long before anyone can merge systems.
• Partner sharing. A distributor or reseller runs Salesforce too, and you exchange leads, opportunities or cases with them.
• Multi-org by design. Regions, brands or regulated units keep separate orgs on purpose, and a central team needs shared accounts or consolidated reporting.
• Special-purpose orgs. A service, support or product org that has to see the customer master from the main sales org.

Each case needs something different. A partner needs a narrow, controlled slice of data. A post-merger team may need almost everything, which is a hint that merging could be the better answer. Decide what problem you are solving before you pick a tool.

What happened to the Salesforce to Salesforce (S2S) feature

For years the obvious answer was the built-in Salesforce to Salesforce feature, usually called S2S. It let one org publish leads, contacts, opportunities and other records to a connected org, which then accepted them. It was free and declarative, and it was also limited, hard to monitor and easy to outgrow.

According to Salesforce’s retirement notice, the feature is being retired in three phases (as of October 2026):

Salesforce’s Summer ’26 architect highlights describe S2S as a low-friction shortcut for scenarios that genuinely needed a more structured pattern, and warn the change will require substantial planning.

Salesforce’s retirement notice recommends testing and validating the new approach in a sandbox without S2S configured, and notes that the recommended alternatives have some license or cost impact. If you run S2S next to its replacement during the transition, expect duplicate records unless both sides match on the same keys.

If you still run S2S, inventory every connection now: which objects are published and subscribed, which fields, which automation reacts to shared records, and which reports or Apex code reference S2S connection data. That list is your requirements document for the replacement.

Your options for connecting two Salesforce orgs

Salesforce’s own replacement guidance names Partner Cloud, Data Cloud One, MuleSoft Anypoint and MuleSoft for Flow. Add Salesforce Connect, custom code and the option of merging, and you get seven routes:

Salesforce Connect cross-org adapter

Salesforce Connect exposes data that lives outside your org as external objects. Its cross-org adapter uses the Salesforce REST API to read records from a provider org and show them in a subscriber org, without storing a copy. It fits cases like “service agents in org B need to see the contracts that live in org A.”

Salesforce’s documentation lists it as an extra-cost add-on in Enterprise, Performance and Unlimited editions. Because each query hits the provider org’s API, heavy list views and reports can use up its daily API allocation.

Data 360 and Data Cloud One

Data 360 (formerly Data Cloud) is Salesforce’s data platform. With Data Cloud One, one home org hosts the Data 360 instance and shares chosen data spaces with companion orgs, which use that data without running their own Data 360.

According to Trailhead, each companion org needs a free Data Cloud One Companion Org SKU, every home org has a maximum number of free companion connections, and converting a home org into a companion later can take months. Choose this when the goal is a unified customer profile and cross-org reporting, not copying opportunities back and forth.

Partner portals instead of a second org

If the “other org” is really a partner, ask whether they need their own Salesforce at all for this process. A partner portal built on Experience Cloud, or Salesforce’s Partner Cloud for full partner relationship management, lets partner users log in to your org with partner licenses and work deals, leads or cases under your sharing rules.

That means no sync, no ID mapping and no loops. It falls short when partners insist on working in their own CRM; then you are back to an integration.

MuleSoft and other integration platforms

MuleSoft for Flow brings prebuilt connectors into Flow Builder as actions, and Salesforce lists it as an option for communication between two orgs; Trailhead notes it is licensed separately.

MuleSoft Anypoint is the route when the flow needs transformation, routing, error handling and orchestration, or when several orgs and other systems are involved. Other iPaaS products (Workato, Boomi, Celigo and similar) connect two orgs with the same pattern. Our Salesforce MuleSoft integration guide covers that platform in depth.

Custom REST integration with Named Credentials

A custom integration calls the other org’s REST API from Apex, Flow (via HTTP callouts or External Services) or a small middleware service. A Named Credential with an External Credential stores the endpoint and OAuth details, so no password lives in code. The target org gets a dedicated integration user and an OAuth client app.

Changes are detected with Change Data Capture, Platform Events or record-triggered flows, then sent as upserts. For the API mechanics, see our Salesforce API integration guide, and for choosing between real-time, batch and event-driven designs, the Salesforce integration patterns guide.

Which option fits you?

Start with who runs the other org, because an acquired company, a reseller and a sister business unit rarely need the same route. The result is the option teams in that position usually pick first.

Merge the orgs or integrate them?

After an acquisition this decision matters more than any tool. A sync between two orgs that hold the same customers, products and processes is a permanent cost: two sets of licenses, two admin teams, and every field change made twice.

A common sequence is to integrate a thin slice first (accounts, open opportunities, a consolidated pipeline report), then merge once the processes are aligned. Build that first integration so it can be switched off cleanly, and use the same external ID fields for the later data migration.

How the data flows

For a two-way sync the design that holds up is simple: every object has one system of record, every synced record carries the other org’s ID, and the integration user’s own changes never trigger a send back.

Object and ID mapping

Salesforce record IDs are generated by each org, so the same customer has a different ID in each one. Never try to force IDs to match. Store the source ID in a unique external ID field on the target object and upsert on it: the REST API then updates the record if the ID exists and creates it if not, which makes retries safe.

Two rules prevent most mapping bugs. Resolve lookups through external IDs too (an opportunity in Org B points to its account by the account’s external ID, not by a hard-coded record ID). And translate record types, queues and users by name or key, because their IDs also differ between orgs and between sandboxes.

How to set it up, step by step

These steps cover the most common path: a custom or iPaaS sync between two orgs, often replacing S2S. Every step happens twice, once per org, so plan the work in pairs. Take the exact Setup screens from Salesforce Help, since labels change between releases.

1. Inventory what existsList current S2S connections, published and subscribed objects and fields, and every flow, trigger, report or Apex class that touches shared records. If there is no S2S yet, list who needs which data and why.
2. Decide merge or integrate, and the system of recordUse the signals above. For each object, write down which org owns it and which direction it moves. Anything without an owner doesn’t sync.
3. Prepare sandboxes in both orgsFull or partial copy sandboxes with realistic data. Point every connection at sandboxes first; production endpoints come last.
4. Create integration usersOne dedicated user in each org, with a permission set that grants API access and only the objects and fields in your mapping. Salesforce includes a limited number of Salesforce Integration user licenses in supported editions.
5. Set up authenticationIn the receiving org, create the OAuth client app the integration logs in through. In the sending org, create an External Credential and a Named Credential for the other org’s My Domain URL. Prefer a server-to-server OAuth flow over stored passwords.
6. Add external ID fieldsCreate unique external ID fields (for example Org_A_Id__c) on each synced object in the target org, and a field for the partner org’s ID on the source side if updates flow back.
7. Build the flowsDetect changes with Change Data Capture, Platform Events or record-triggered flows, then upsert on the external ID through the REST API or your platform’s Salesforce connector. Use composite or bulk requests for volume, and send parents before children.
8. Add loop protection and error handlingSkip changes made by the integration user, compare values before writing, and log every failure with the record ID and the reason. Alerts go to a named owner.
9. Backfill and test real scenariosLoad existing records once, then test: new record, update on each side, the same record edited in both orgs, a deleted record, an owner who doesn’t exist in the other org, a new picklist value, and a bulk update of several thousand records.
10. Run in parallel, then cut overIf you are replacing S2S, run both for a short pilot and watch for duplicates; then switch off S2S connections, remove automation that depends on them and monitor the new flows daily for the first weeks.

Built by Gilzor

Results we’ve shipped

70+products launched

98%delivered on time

85%clients come back

Aviation33%faster baggage weigh-inWeb and Mobile application for Airlines→Healthcare+30%lab test ordersMedical Lab Web and Native Mobile Applications→Retail · Startup700+stores aggregatedMobile application for Grocery shops→

Talk to the people who build it. Tell us about your project and get a free estimate of scope, timeline and cost.

See how we’d approach yours →

Pitfalls and how to fix them

When a custom integration makes sense

Out-of-the-box options cover reading another org (Salesforce Connect), sharing a data layer (Data 360) and letting partners in (portals). Custom work, on your own code or on MuleSoft, starts to pay off when:

• Records must move both ways with field-level ownership and conflict rules.
• Data has to be filtered, transformed or approved on the way, for example only closed-won deals from one region.
• You run three or more orgs, or the orgs also feed an ERP; see the integration patterns guide for hub and event-driven designs.
• The integration is a bridge to a merge and must reuse its IDs for the final migration.

A typical build has change capture in each org, a small service or MuleSoft application in the middle, a mapping table for users, picklists and record types, a retry queue and alerts. Expect most of the effort in mapping and testing, not in the API calls.

Multi-org programs that touch an ERP land higher than these figures. The ranges, and what moves a project within them, come from our API integration cost guide. If the orgs also need to connect to other systems, the Salesforce integration guide covers the wider picture.

Go-live checklist

Fill it in with both org admins in the room. Most org-to-org failures come from a decision one side assumed the other had made.

FAQ

Where Gilzor fits

With S2S retiring in Spring ’27, many teams now have to replace a connection they never had to think about. Gilzor is a software development company with engineers in Poland and Cyprus, not a Salesforce reseller. We can help you weigh merging against integrating, map records and IDs between the orgs, and build and support the replacement sync on custom code or MuleSoft; scoping is described on our Salesforce integration services page.