Salesforce provides a default feature through which two different customers can share data between their orgs called "Salesforce to Salesforce". It provides a mechanism to set up a formal connection between two orgs, determine which objects can be shared and also which fields within those objects can be shared. The records can then be shared, manually or programmatically.
Steps for Salesforce to Salesforce (S2S)
Enabling Salesforce to Salesforce
To use Salesforce to Salesforce (S2S), you have to enable it. This has to be done in both the orgs by Users (usually System Administrators) who have "Manage Connections" permission on their profile.
To enable, navigate to Setup >> Build >> Customize >> Salesforce to Salesforce >> Salesforce to Salesforce Settings. Hit Edit, select Enable, and then select Save.
Note: Once the preference is enabled, it cannot be disabled.
Once enabled in your org, you can customize the invitation by modifying the From email address, Display name and Email templates used for sending the invitation emails.
Setting up a Connection
Assuming both the orgs have S2S enabled, we now need to establish a formal relationship between the orgs before the actual sharing of records can take place. This is done by setting up a Connection as described below:
Go to Connections tab. If you don't have one, Click the plus (+) symbol on the tabs menu and search for Connections
On the Connections tab, click New to create a new connection with another org.
Select a contact under an account representing the other org you want to share records with via S2S, and click Save & Send Invite. The invitation email will be sent to the email address under the selected contact.
As a best practice, in the Source org, create an account representing the destination org that will receive the connection, and also create a contact with email address under that account. This contact will typically be used when sending the S2S connection invitation.
Also define an owner for the connection who will receive all email notifications including system notifications in case there is a functional error when the connection is inserting/updating a record. Additionally, the connection owner will be assigned as the default owner of any new records. This may however get overridden by any assignment or other rules that determine record ownership.
When you click Save & Send Invite, the Destination user will receive an email with a link to Accept or Decline the invitation.
Click on the link, Login and hit Accept for the connection to start sharing records.
Once the connection is established, the next step is to publish and subscribe to objects. Both source and destination orgs can publish and subscribe to each other's objects and fields.
To Publish objects click on Publish in the Connection tab, and select the object that you wish to publish.
Select Edit on an object to choose the fields that you wish to publish to the other org.
Subscribing to Published Objects
The destination org doesn't automatically have access to the data published from the Source org. Instead, the org needs to first subscribe to the objects published.
For this login to the destination org subscribe to an object and map the fields. This is done by navigating to the Connections tab, selecting the designated connection, and hitting Subscribe.
An additional flag Auto-Accept is sometimes displayed. If this option is selected, then records from the publishing org will be automatically accepted. If you don't select the checkbox, then an administrator will first have to review incoming records before they are accepted. The checkbox is not always displayed. In particular, child objects are automatically accepted if parent objects are accepted, and the option is not available for junction objects either.
Click Save and this completes the object level mapping. Now you need to map the fields. Do this by clicking on Edit next to the subscribed object.
Field Mappings considerations
You may have come across situations where certain fields are not available for publishing, or where you are not able to subscribe to map some fields onto other fields. Here's a little more about this field mapping and how to resolve these.
Data Type matching - Only matching data type fields can be mapped. In other words, the mapping enforces field type, dimension and precision. So for example, you can map a text field to any other text field of equal or greater length. Lookup or reference fields can be mapped to text fields (of size 80 or greater), and auto-number fields can also be mapped to text fields (of size 30 or greater).
Field visibility - Lookup IDs are not available for publishing. You can enable S2S for those fields by creating a formula field and then publishing the formula field. In advanced section of formula field, select treat blank as blank.
A one-way share between two orgs is achieved by having the source org publish, and the target org subscribe. The source org then acts as a master and would overwrite shared records in the target org whenever there is a change to the record in the source org. Any changes made to the shared record in the target org are lost when the source org record changes in this scenario.
A two-way share between orgs is achieved by having both orgs publish and subscribe to each others objects. Shared records in this case between the two org will synchronize whenever there is a change in record on either side.
In both cases, the Salesforce to Salesforce mapping will determine which fields would flow from one org to the other.
Records can be shared in two ways , either manually or programatically.
Manual Sharing of Records:
Go to List view for the object and Select the records and click on Forward to connection.
Select the connection and related objects if there are any, and save. Note that only users with the Manage Connections profile permission will see the Forward to connection option. Also, users can forward only those records that they are the owner for or those owned by their subordinates (role hierarchy). System administrators can share any record.
Records will be automatically created in the destination org if the auto-accept for the object is enabled. If not enabled, the records sent need to be explicitly accepted in the destination org. This can be done by selecting the object (Account in this example) tab and click on the Go button in Accounts from connections:
Then click on Accept to accept the record in the destination org.
Programmatic sharing of records via Apex
Records can be shared for supported objects programmatically (via triggers, batch process, etc.). Programmatic sharing gives a higher level of control over how you share records and also makes it possible to carry over hierarchy/relationship to the destination org. Here is sample code snippet to share a contact record via S2S programmatically.
PartnerNetworkRecordConnectio newConnection = new PartnerNetworkRecordConnection( ConnectionId = networkId, LocalRecordId = newContact.Id, SendClosedTasks = false, SendOpenTasks = false, SendEmails = false, ParentRecordId = new Contact.AccountId); insert newConnection;
At inteygrate.com, I am trying out ways to integrate Salesforce to various other technologies.