In my previous post, I discussed how all the existing Accounts and Contacts in the database can be transferred from one Salesforce instance to another by enabling two Salesforce instances to communicate with one another. In this post, I’ll describe how to subscribe to these published objects, the use cases for Salesforce to Salesforce and how to overcome challenges you may have with the integration.
Subscribing to Published Objects:
The destination environment doesn’t have automatic access to the data published from the source environment. Instead, the org must first subscribe to the objects – login to the source instance and subscribe to these two objects and map the fields. This can be done by navigating to the Connections tab, selecting the destination connection, and hitting Subscribe. You’ll now be presented with a list of the published objects to which you can subscribe.
The image above essentially declares the mapping between the objects from the source instance and the objects to which they’ll map in the destination instance.
An additional flag is sometimes displayed – Auto-Accept. Upon selecting this option, records from the publishing org will be automatically accepted and the process will be entirely automatic.If the checkbox isn’t selected, 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. Clicking Save completes the object level mapping. That is, we’ve defined which object from the source instance maps to which object in the destination instance. Now we need to map the fields. This can be done by clicking Edit next to each object. Here, we edit the Account object.
Now map the published Account and Contact fields from the source Instance to the Account fields in destination instance:
Clicking Edit beside the Account object in the subscribe objects list in the destination instance allows you to map Account fields in the source instance with Account fields in the destination instance.
As the above diagram shows, we’ve mapped each field to the same object field in the receiving environment.
Use Case Of Salesforce to Salesforce:
Users in Salesforce1 with Manage Connections permission can share records using Salesforce to Salesforce. By using this mechanism, the user can transfer an Account or Contact which was created in source instance to destination instance.
|Actors||High Level Use Case||Details||Exceptions|
|Salesforce.com User.||Any user with Manage Connections permission can forward Account from source instance to destination instance||
||The selected Account record gets forwarded to destination instance. We can find the Account record which was transferred in the destination Account object as a record which was forwarded through external connection.
|Salesforce.com User.||Any user who is having Manage Connections permission can forward Contact from source instance to destination instance.||
||The contact record which was forwarded is displayed in the destination instance
What are the Challenges?
We implemented custom code to generate an acknowledgment when the record is transferred using Salesforce to Salesforce. In order to confirm whether the record is forwarded using Salesforce to Salesforce connection, we used the following procedures:
- We created a checkbox field Named Externally Shared in Account object in Source instance.
- We ran a Batch Apex to make that Externally Shared check box is checked if the record is shared externally
We noticed a few issues while transferring records from source to destination where triggers and validation rules create obstacles which prevent the record from getting transferred to the destination instance.
By-Passing destination salesforce instance Triggers:
While forwarding records from one Salesforce instance to another, we might find triggers which were configured at the destination. These triggers may fire when forwarding the record using the Salesforce to Salesforce connection, which in turn causes an error when inserting or updating the records while forwarding from the source Salesforce instance to the destination Salesforce instance.
In order to prevent these triggers from being fired while forwarding records using the Salesforce to Salesforce connection, we can use the following approach. (Note: When any record is forwarded from source to destination, the records created by user detail will be saved as Connection User.) By preventing the trigger in the destination instance from being fired for that particular connection user, we can control the effect of the trigger on the record while forwarding using Salesforce to Salesforce.
Organization org = [select id from Organization ];
string user = ‘partnernetwork@’+org.id+’.pnet’;
The above code is used to restrict the trigger from being fired when the record is forwarded using the Salesforce to Salesforce connection. As I mentioned earlier, when a record is created or updated using the Salesforce to Salesforce connection the created by user is saved as Connection User. If we can prevent the trigger from being fired for that particular user, then we can insert or update records without having any effect from the trigger in the destination.
In order to work with system debug logs for Connection User, we can use the following URL in the system debug logs page:
An ID of the connection user has to be used in place of UserLookupInput_Ikid=yyyyyyyyyyyy where we can get the UserLookupInput_Ikid id by using view pagesource in the record view mode page and on searching for the connection user in the source code. The ID has to be used in place of yyyyyyyyyyy. By using the above URL in system debug logs, we can get the connection user who’s named as email@example.com. Here, ID represents the Salesforce.com organization ID of the user.
For more information about Salesforce to Salesforce integration, please refer to the following links:
Next features: The many ways to transfer a record using Salesforce to Salesforce and customizations performed to improve the features of Salesforce to Salesforce.