Salesforce-to-Salesforce (S2S) is a native Salesforce feature that lets two separate Salesforce orgs share records with each other through a publish-and-subscribe connection — the sharing org publishes objects and fields, the partner org subscribes, and forwarded records are inserted and kept in sync without any custom code.
It is the simplest way for two companies that both run Salesforce — say a vendor and a distributor, or a parent company and a subsidiary — to exchange leads, opportunities, cases, or custom records while each side keeps full control over exactly what it shares.
Key takeaways
- S2S shares records between two Salesforce orgs using a native publish/subscribe model — no middleware, and no code required to get started.
- Data is copied, not referenced: a subscribed record becomes a real record in the receiving org and stays linked so later updates flow through.
- Each org stays in control — you choose which objects and fields to publish, and either side can stop sharing at any time.
- Setup is point-and-click: enable S2S, send and accept a connection invitation, publish objects, subscribe, and map fields.
- S2S is best for partner record sharing, not large-scale system integration — for that, MuleSoft, Data Cloud (Zero-Copy), or API-based middleware are the strategic choices in 2026.
What is Salesforce-to-Salesforce?
Salesforce-to-Salesforce (often shortened to S2S) is a built-in collaboration feature that connects two distinct Salesforce orgs so they can share records directly. Instead of exporting spreadsheets or building an integration, the two orgs establish a trusted connection, and from then on records flow between them based on rules each side defines.
The model is publish and subscribe:
- The publishing org decides which objects (Lead, Opportunity, Case, Product, or custom objects) and which fields it is willing to share.
- The subscribing org chooses which of those published objects it wants to receive and maps the incoming fields to its own fields.
Because both orgs run Salesforce, the shared records land as native records in the receiver — they can be reported on, automated, and edited like any other record (subject to what the publisher allows). A key point for 2026: S2S is a long-standing, stable feature aimed at business-to-business record sharing between partners, not a general-purpose integration platform.
How do you set up an S2S connection?
Setting up Salesforce-to-Salesforce is entirely point-and-click. The legacy menu path has changed over the years, so use Setup's Quick Find search rather than memorising a menu tree.
1. Enable Salesforce-to-Salesforce (in both orgs)
In each org, go to Setup → Quick Find → Salesforce to Salesforce Settings, click Edit, tick Enable, and save. Note: once enabled, S2S cannot be turned off again — but you can stop sharing or change what you share at any time, so leaving it enabled is safe.
Also confirm the user who will run connections has the Manage Connections permission on their profile or permission set.
2. Add the Connections tab
Add the Connections tab to your app (or open it from the App Launcher). This is where invitations, published objects, and subscriptions are managed.
3. Create an Account and Contact for the partner org
In the sending org, create (or reuse) an Account representing the partner company and a Contact with a valid email address. The invitation is sent to that contact.
4. Send and accept the connection invitation
On the Connections tab in the sending org, click New Connection, pick the partner contact and account, and choose Save & Send Invitation. The partner receives an email with a link that opens in their org; on their Connections tab they can Accept, Decline, or Decide Later. Once accepted, the connection is live.
5. Publish objects and fields (sending org)
On the connection record, click Publish/Manage, select the objects to share, then Edit each object to choose exactly which fields to publish. Publishing makes objects available — it does not push them yet.
6. Subscribe and map fields (receiving org)
In the partner org, open the connection and click Subscribe/Manage. Choose which published objects to receive and map each incoming field to a local field of the same data type (only matching data types can be mapped). Turn on Auto-Accept if you want forwarded records inserted automatically instead of landing in a review queue.
7. Forward records (and auto-forward new ones)
Even after publishing, individual records are not shared until they are forwarded. Users can forward manually from the record's Forward to Connections related list. To do it automatically, build a record-triggered Flow that creates a PartnerNetworkRecordConnection record whenever a qualifying record is created. (Workflow Rules and Process Builder are retired — use Flow.)
// Auto-forward a record to a connected org in Apex (or from an invocable
// action called by a record-triggered Flow). Salesforce-to-Salesforce uses
// PartnerNetworkRecordConnection to forward each record over a connection.
PartnerNetworkConnection conn = [
SELECT Id
FROM PartnerNetworkConnection
WHERE ConnectionStatus = 'Accepted'
AND ConnectionName = 'Acme Distribution' // the partner org's connection
LIMIT 1
];
PartnerNetworkRecordConnection share = new PartnerNetworkRecordConnection(
ConnectionId = conn.Id,
LocalRecordId = opportunityId, // the record you want to publish
SendClosedTasks = true,
SendOpenTasks = true,
SendEmails = true
);
insert share; // the record is now forwarded to the subscribing orgWhich records and fields can you share?
S2S supports most standard objects and custom objects, but there are real constraints to design around:
- Field mapping must match data types. A Text field maps to Text, a Number to Number, and so on — you cannot map a Picklist to a Date, for example.
- Formula fields, roll-up summaries, and some system fields cannot be shared directly; share the underlying data instead.
- Child records follow their parent when you also publish and subscribe the related object (for example, sharing Opportunity Line Items alongside Opportunities).
- The subscriber controls its own automation. Validation rules, required fields, and triggers in the receiving org still apply to forwarded records, which is the most common reason records silently fail to insert.
If you are loading or reconciling large volumes alongside S2S, our guides on importing records with Data Loader and managing large data volumes with skinny tables and indexes are useful companions. For governance, see our Salesforce customization best practices.
Salesforce-to-Salesforce vs other integration options
S2S is purpose-built for one job: sharing records between two Salesforce orgs. The moment your needs grow — many systems, non-Salesforce endpoints, live (not copied) data, or AI and analytics use cases — a different tool fits better. Here is an honest 2026 comparison:
| Approach | Real-time vs batch | Data copied or referenced | Setup effort | Best for |
|---|---|---|---|---|
| Salesforce-to-Salesforce (S2S) | Near-real-time on forward | Copied (lands as a real record in the subscriber) | Low — clicks, no code | Two Salesforce orgs sharing records (leads, opps, cases) with partners |
| Salesforce Connect (OData external objects) | Real-time, on demand | Referenced (live, never stored) | Medium — needs an OData source or adapter | Viewing external data live without copying it into Salesforce |
| MuleSoft / MuleSoft Composer | Real-time or batch | Either — you design it | High (MuleSoft) / Medium (Composer) | Many systems, complex transforms, enterprise-grade integration |
| Data Cloud sharing / Zero-Copy | Near-real-time / federated | Referenced (zero-copy) or unified | Medium–High | Unifying customer data for analytics, segmentation, and AI agents |
| REST / Bulk API + middleware | Either — you build it | Copied | High — custom code | Custom sync logic, high volume, or non-Salesforce endpoints |
The honest summary: reach for S2S when both sides run Salesforce and you simply need to share records with a partner. Choose MuleSoft when you are integrating multiple systems with transformation logic, Salesforce Connect when you need to see external data live without storing it, and Data Cloud / Zero-Copy when the goal is a unified customer view for analytics and AI. For a broader look at the options, read 10 ways Salesforce integration improves business performance.
Common S2S pitfalls to avoid
- Records publish but never arrive. Publishing only makes an object available — each record still has to be forwarded, manually or via Flow/Apex.
- Silent insert failures in the receiver. The subscriber's validation rules, required fields, and triggers apply to forwarded records. Check the connection's error logs first.
- Field mapping drift. Adding a field on the publishing side does not auto-map it downstream; revisit subscriptions when schemas change.
- Treating S2S as full integration. It shares records, not business logic. If you need transformation, orchestration, or non-Salesforce systems, plan for MuleSoft or API middleware instead.
Frequently Asked Questions
What is Salesforce-to-Salesforce used for?
Salesforce-to-Salesforce (S2S) is used to share records between two separate Salesforce orgs without custom code. It is most common for business partnerships — vendors sharing leads with distributors, agencies passing opportunities to clients, or a parent company exchanging cases with a subsidiary. One org publishes objects and fields; the other subscribes and maps them, and forwarded records sync between the two.
Is Salesforce-to-Salesforce a separate product to buy?
No. Salesforce-to-Salesforce is a native, standard feature, so there is no separate add-on to purchase — it works between two existing Salesforce orgs once enabled in each. Licensing of the underlying orgs is a separate matter you should confirm with your Salesforce account team.
Does Salesforce-to-Salesforce copy data or reference it?
S2S copies data. A forwarded record becomes a real, native record in the subscribing org rather than a live reference. The two records stay linked, so updates from the publisher flow through, but the subscriber holds its own stored copy. If you need to view external data live without storing it, use Salesforce Connect (OData external objects) instead.
Can you disable Salesforce-to-Salesforce after enabling it?
No. Once Salesforce-to-Salesforce is enabled in an org it cannot be turned off again. However, this is low risk because you control all sharing: you can deactivate connections, stop publishing objects, and change field mappings at any time, so enabling the feature does not expose any data on its own.
How do you automatically forward records in Salesforce-to-Salesforce?
Publishing an object makes it available but does not push individual records — each record must be forwarded. To automate this, build a record-triggered Flow (Workflow Rules and Process Builder are retired) that creates a PartnerNetworkRecordConnection record when a qualifying record is created, or call an Apex invocable action that does the same. Users can also forward records manually from the record's Forward to Connections related list.
Should I use Salesforce-to-Salesforce or MuleSoft?
Use Salesforce-to-Salesforce when both sides run Salesforce and you only need to share records with a partner — it is point-and-click and needs no code. Use MuleSoft (or MuleSoft Composer) when you are integrating multiple systems, transforming data, or connecting to non-Salesforce applications. In short: S2S for partner record sharing, MuleSoft for enterprise integration. For unifying data for analytics and AI, consider Data Cloud with Zero-Copy.
Get expert help with Salesforce data sharing
Choosing between Salesforce-to-Salesforce, Salesforce Connect, MuleSoft, and Data Cloud — and configuring publish/subscribe rules, field mappings, and auto-forwarding correctly — is where many integrations stall. MicroPyramid has delivered Salesforce projects since 2014, and our certified team can design the right data-sharing architecture for your orgs and build it end to end. Explore our Salesforce consulting and development services to get started.