This presentation explains how to use Salesforce.com platform Salesforce to Salesforce (S2S) feature effectively to integrate multiple salesforce organizations, enable collaboration of accounts, contacts, leads, leads assignment, conversion and SFA collaboration across multiple salesforce organizations.

1. Multi Org Collaboration Using
Salesforce to Salesforce
Mayur Shintre | Salesforce.com
April 2012
#S2S #MultiOrg #Integration

2. Outline
 What is „Salesforce to Salesforce‟ (S2S)?
– What is it? What can it do? What it can‟t?
 The Business Case
– Why spend the money? Why use S2S?
 S2S Implementation
– The devil is in the details
 Multi Org Collaboration
– Record Sharing – Data Hub
– Account & Opportunity Collaboration
– Centralized Campaign & Lead Management
– Cross Org Case Collaboration

3. What is S2S?

4. What is S2S?
 Salesforce to Salesforce (S2S) is a force.com platform based
framework that enables sharing of data from one Salesforce.com
Org to another. The data never leaves the platform
 Originally designed to share data with your partners (and still is),
S2S can be a practical and cheap option to integrate and share
data across multiple Salesforce.com Orgs to enable Multi Org
Collaboration

5. What is S2S?
 S2S actually shared data between two Orgs. Data gets physically copied
from source to target (hub) Org by the S2S framework
Contact
Account
Eric Foreman
111-111-1111
 Once shared, S2S maintains and reflects updates from the source to the
target
 Sharing of data between Salesforce Org‟s using S2S can be done
manually (via the GUI) or automated (via APEX code)

6. What is S2S not?
 S2S is not for sharing data to an entity external to Salesforce.com
platform
 Not a „true‟ middleware substitute – It wont perform translations,
transformations and validations. You still have to do them in Apex
• Does no enrich data from 3rd party sources
• Not a replacement for serious ETL use cases
• S2S does not have an SLA. So latency must be accounted in your
architecture for transferring & sharing parent – child records

7. Why Use S2S?

8. Why Use S2S?
 If you want continuous sharing of data across two or more SFDC Org‟s
 Data can be published and subscribed to, on-the-fly
– Independent of programmatic logic & trigger functions
 Reduce moving parts for integration
– Avoid data travelling externally and back to the platform
 Eliminates the need for third party integration tools
– Informatica, Cast Iron, TIBCO etc…
 Benefits from Salesforce.com‟s seamless platform upgrades
– No patching, upgrading & maintenance hassles and service interruptions

9. Why Use S2S
 Powerful tool to implement SFA or Multi Org Collaboration across
Multiple Organizations
– Record Sharing – Data Hub
– Account & Opportunity Collaboration
– Centralized Campaign & Lead Management
– Cross Case Collaboration
 Integrate your business processes with updates received from
Another Org using workflow and assignment rules
 Its free for all editions – including group and contact editions
 Cheaper to implement, operate and maintain

10. Taxonomy – Same as…
 Spoke Org  Hub Org
 Business Unit  Corporate Org
 Child Org  Target Org
 Source Org  Destination Org
 Business Org  Corporate Hub
 End Org
Note - Multi Org Collaboration and S2S are not one and the same. Multi
Org Collaboration (a business process) can be achieved by using S2S, a
Force.com platform based data sharing framework.

11. Implementing S2S

12. Implementing S2S
 Details on configuring S2S
– www.scribd.com/doc/24252711/Salesforce-to-Salesforce-Implementation-Guide
– developer.force.com/consultants/crc_page?name=SalesforceToSalesforce
 There is plenty of good documentation on configuration and use of
S2S
– Instead, we will concentrate on S2S implementation details for Multi
Org Collaboration using S2S automated sharing mechanism

13. S2S – Sharing Automation
 S2S allows automated sharing of data between two connected Orgs using
Apex triggers
 When you „enable‟ a Salesforce.com Org to use „Salesforce to Salesforce‟,
two new objects are exposed for programmatic access
– PNC (Partner Network Connection)
• Stores the ConnectionID for an established connection between two Orgs
– PNRC (Partner Network Record Connection)
• Insert records you want to share in this object
• Records are shared over a ConnectionID
 One PNC & PNRC object per Org – both connected Orgs get a PNC and a
PNRC object of their own

14. S2S – Sharing Automation Insert RecordID to
PNRC Object – After
Insert or After Update
Account Object Action
RecordID Account Name Phone
222 GenePoint 800-444-3456
BU Org PNRC Object
Business Unit ConnectionID LocalRecordID PartnerRecordID
Org 001d000000ArlFb 222 444
1
2
Salesforce to Salesforce Platform Framework
4
Central Org PNRC Object 3
ConnectionID LocalRecordID PartnerRecordID
001d000000ArlFb 444 222 Central Org
Account Object
RecordID Account Name Phone
444 GenePoint 800-444-3456

15. S2S – Record Sharing
 After Insert Trigger must be implemented on each object whose records
you want to share with another Org
– This Trigger performs the action of collecting, sorting and filtering through the
list of records from the trigger context
– Insert DML operation in the PNRC Object of the Source Org
PNRC PNRC
Contact Contact Record
S2S Contact Record
Contact
Trigger Trigger
 The insertion of the RecordID‟s in the PNRC object are done by specifying a
Connection to a Target Org.
– The ConnectionID‟s are stored in the PNC (Not PNRC) object
 Certain relationships can be transferred with a record
– Contact, Opportunity  Account ; Case Note  Case
– There are exceptions to the rule

16. S2S – Hierarchies & Relationships
 S2S allows for automated sharing of parent and child records
 When sharing a Contact, you want to automatically share the it‟s
parent Account
– In Apex set ParentRecordId = Account.Id
 When sharing an Account, you want to automatically share all it‟s
Contacts
– Set RelatedRecordId = Contact.Id
– A comma-separated list of API names for child records to be shared
with a parent record.
 When sharing an Account, you want to automatically share all
related Open and Closed Tasks
– Set SendClosedTasks & SendOpenTasks to true

17. S2S – Hierarchies & Relationships
 This will work fine for simple hierarchies
– Contact  Account
– CaseComment  Case etc.
 However, S2S does not accommodate for parent Hierarchies and
not work for
– Account  Parent Account
– ParentRecordId = Account.Id on Account trigger will
not work
– This is a S2S nuance
Error!
Account PNRC
Account w Parent
S2S
Trigger

18. S2S – Hierarchies & Relationships
 To share parent hierarchies e.g. Account – Parent Account
– Copy ParentID via workflow rule to a text field
– Send the ParentID via S2S mapping
– Write Batch Class in Target Org to stitch Parent relationships
 Points to note –
– Parents must be shared for automatic linking
– Parent record many not exist on destination
• Not sharing Account Objects
• Parent sharing hasn‟t completed yet
 Trigger must account for potential sharing delay

19. S2S – Sending Related Tasks
 Send Open and Closed Tasks related to a record via APEX
 However there is a big catch
– These tasks are sent one time, as a static snapshot only
– What does this mean? Take the following example
 Contact – Bob Smith
– Open Task 1
– Closed Task 2
 S2S initiated – Contact Bob Smith (with Open/Close Task) is shared
– Open Task 1 and Close Task 2 are shared with the other org
– At a later time Open Task 1 is closed, new Open Task 3 is created – Task 1 update and
Task 3 will not be shared
 To share tasks continually
– Implement a trigger on Task Object and share Tasks explicitly.

20. S2S – Defining Record Ownership
 Connection User - S2S Records owned by default
– Non-query able User object
– Listed as “Created By” and “Last Modified By”
 Initial owner of record is owner of connection
– Maintaining ownership of shared records is integral for SFA use cases
– Maintain ownership and security
– Source Org record owner must also be the Target Org record owner
– Think about User provisioning and Licensing
Owns Record
Requests Access

21. S2S – Defining Record Ownership
 All Active Users from Business Units must exist in the Hub Org
 User Provisioning Business Units
– Near real-time sync between
Hub Org
• Business Units and Hub Org
• Hub & Spoke model only
– User License type matters
– E.g. - For SFA collaboration
• Hub User cannot be of license type „Portal User‟
• License type should have CRUD access to desired objects
– User Profile in Hub Org must provide appropriate CRUD access
 Assign correct ownership once User provisioning is in place
– Required custom Ownership Assignment logic in the Hub Org (or any Target Org)

22. S2S – Defining Record Ownership
 Solution – Write a „Ownership Class‟ in the Hub Org
– Write a „Fetch User‟ sub-class
– This class should query and fetch the correct owner based on email ID
• Standardize and match email variants
• Source Org - eforman@salesforce.com; Target Org – eric.forman@sfdc.com
Assign Record Ownership
User
Contact
PNRC PNRC Fetch
Trigger
Contact Record
S2S Contact Record Before User Contact
Insert
Trigger
– Once the correct owner is fetched, check the user license type and CRUD
• Possible with the new UserRecordAccess API Object released in Spring 12
 Insert record and assign record ownership

23. S2S – User Provisioning
• In order to maintain ownership a User created in the Source Org must also
be initiated in the Target Org
• In Hub-Spoke Multi Org pattern, every SFA user in the spoke will be
required in the Hub Org
– User licensing is a top concern
– Client will not want to pay twice for each license
– Please involve your Account Executive
 Complete User provisioning in the Hub Org is pivotal for Multi Org
Collaboration success
– Do not let licensing be an afterthought or an hindrance for success
– Make sure Hub Org user licensing has been ironed out beforehand

24. S2S – Lead Conversion Process
 If you share or assign Lead records from Hub  Spoke
– Leads may get converted at the spoke (Business Unit)
– Once Converted – The Lead is not available to S2S
– S2S severs the connection of the Lead record
 Approach 1 – Tie Converted records back to the Lead in Hub
– Create a proxy Object to store ConvertedId‟s
– Use Lead conversion API to copy ConvertedID‟s to proxy object
– Copy the ConvertedAccountID, ConvertedOpportunityID &
ConvertedContactID – Accessible via API in the Lead Object
– Share the ConvertedID’s to the Hub Org via S2S
– Implement a Batch Class to query the PNRC object to fetch
LocalRecordID’s
 Tie Converted Account, Contact & Opportunity to the Lead in the Hub Org

25. S2S – Lead Conversion Process
 Approach 1 – Tie Converted records back to the Lead in Hub
Lead Converted
1
Account
x 5
Lead Account
Lead Tie ACO to Lead Lookup fields
Lookup
Contact
Contact Relationship
2 Copy ConvertedID‟s
Opport
Opport
unity
unity
Batch
Proxy 3 Proxy
Class
Custom
PNRC PNRC Custom
Object
Trigger
RecordID
S2S RecordID
Object
Query Local Record Id‟s 4
 Approach 2 – Reflect full lead conversion process in the Hub Org
– Using S2S, perform actual lead conversion in the Hub Org using the Lead Conversion API
– Can be done, but not trivial
– Use case - True SFA sync across Multiple Orgs

26. S2S – Record Deletion
 Salesforce to Salesforce does not have deletion sync
 When a shared record is deleted from the source, It does not get
automatically deleted in the target Org
 Solution - Implement a Batch Class in the Target Org
Query Scheduled
Record Delete
Apex to sync
PNRC PNRC deletes
Account LocalRecordID= null S2S ParentRecordID = null Account
Batch
Trigger
Class
Delete
– When a record in the source Org is deleted it‟s LocalRecordID value in the
PNRC object is set to null
– You can run a query in the Target Org PNRC Object
– Fetch all records where PartnerRecordID = null

27. Data Migration

28. S2S – Data Migration
 When a Salesforce to Salesforce project involves Multi Org Collaboration
– The implementation depends on explicit sharing of all records via S2S
– This is because the continuous sharing is dependent on the connection initiated via S2S
framework
– So records must be transferred via S2S and not externally via a ETL tool
 Successful data migration is dependent on the following factors
– Correct User Provisioning
– Correct User License Type
– Correct User Profile
– A parent cannot be a lookup field in the Target Org‟s Child object
• E.g. When sharing a Contact (and it‟s Parent Account) – If Hub Org Contact object has a custom
Account lookup field
• The related Account will go in a manual queue
– Transfer records in batches of descending Hierarchies
1. Send Parent Accounts
2. Send Child Accounts
3. Send Child Opportunities
4. Send Child Contacts etc.

29. Multi Org Collaboration

30. Multi Org Collaboration – Why?
 Company made up of several independent operating business units
 Each business unit runs independently as a corporation and run‟s
it‟s own Salesforce Org for SFA
 This causes Silos of data and processes. Corporate unable to get a
360 „global‟ view on their business.
 Collaboration between sales teams from different business units
does not exist due to lack of visibility
 Leveraging existing Opportunities & Contact for common Accounts
& existing relationships across other business units.

31. Multi Org Collaboration
Salesforce to Salesforce can been harnessed to implement many Multi
Org collaboration use cases. Here are a few that have been
implemented at some of our enterprise clients.
Hub-Spoke Pattern
1) Record Sharing
1) Global 360 view of Account, Contact, Opportunities across all businesses
2) Global Metrics for Forecasting & Reporting
2) Account & Opportunity Collaboration Across Business (Orgs)
3) Centralized Campaign Management & Lead Assignment
Federated Pattern
4) VCE Use Case
4) Case Routing Collaboration between Orgs

32. 1. Record Sharing
 Organization made up of several operating business units
 Each business unit runs independently as a corporation and run‟s
it‟s own Salesforce Org for their SFA
 This causes Silos of data and processes.
– Unable to get a 360 view on their business.
– Account, Contact & Opportunities
 Collaboration between sales teams from different business
units did not exist
 Global Forecasting
 Harnessing existing and common relationships across the
Organization is marred due hermetically sealed (in)visibility
– Utilizing existing relationships (Contacts) from other Orgs for an Account

33. 1. Record Sharing – Data Hub
“Business Divisions”
• Global Reporting
• Forecasting
Medical • 360 View of Sales
“Corporate Org”
Hub
Electronics S2S Org
Telecom

34. 2. Account & Opportunity Collaboration
 Collaborate on SFA records across organization barriers
 Allow Sales Users to collaborate across Org‟s on Account & Sales
Teams
 Account Access request‟s seamlessly integrated via Email
Approval
– User from Org A requests access to Account from Org B
– Account Owner in Org B gets Account Access Approval email
– Owner replies „Yes‟ or „No‟ to email
– User from Org A gets Access to Orb B user‟s Account‟s, Contact‟s and
Opportunities
 Access can be customized via Managed Apex to add to Sales
Team or individual record access

35. 2. Account & Opportunity Collaboration
User Gets Access
Approval Email
1 3
Owns Record
5 User Approves
Owns Record
5 Requester Gets Access
Requests Access
2

36. 3. Centralized Campaign & Lead Management
Monitor Enrich
Plan Execute Identify Qualify Send Lead
Measure Lead
Campaign Campaign Lead Lead Over S2S
Campaign Data
Hub Org
Re- Update
Distribute Original
Lead Lead Send Converted
Send Status A,C & O Over S2S
Over S2S
Send Lead
Business Over S2S
Org 1
Reject Convert Work Assign
Lead Lead Lead Lead
Business Work Convert
Org 2 Lead Lead Send Converted
A,C & O Over S2S

37. 3. Centralized Campaign & Lead Management
“Business Divisions”
Medical
“Corporate Org”
Lead
Electronics Hub
S2S
Telecom

38. 4. VCE Case Collaboration
1. Case created in legacy case management system
2. Case transferred to Salesforce via integration
3. Case shared to “Shared Org” via S2S
4. Shared Org shares cases to partner orgs
5. Cases passed via integration to legacy systems
6. S2S automates ongoing updates
Most current version of all objects
are on all systems at all times

39. 4. VCE Case Collaboration
EMC SFDC
“Skinny Org”
Cisco SFDC
VMware SFDC
“Skinny Org”
“Skinny Org”
Central VCE
“Shared Org”

40. Recap
 S2S – A powerful Cloud based data sharing framework
 Between Salesforce Org‟s only
 Think about Courtesy Licenses in Hub Org
 SSO implementation for seamless access & simplicity
 Data Migration Planning via S2S
 Multi Org Collaboration Use Cases
 Single or Bi-Directional Integration
 Bi-Directional Integration not trivial
 Proper Lead Conversion not trivial