Estimate effort of a Salesforce-to-Salesforce project

One of my customers wants to bidirectionally synchronize a handful of Sales Cloud and Custom Objects between two of its business orgs. Using Salesforce-to-Salesforce. I never did such a project before and don’t know how to estimate/scope/price the effort.

Sure there is an official documentation which describes the steps which look easy and straight forward, but I fear there are hidden risks that only developers experienced with S2S know.

Questions that come into my mind are:

  1. How do I turn on this feature?
  2. How much does it cost?
  3. Is it cumbersome to get licences as many things with Salesforce?
  4. Is S2S a supported feature and best of breed or is there something better (e.g. Mulesoft)?
  5. What makes S2S projects easy and what makes them hard.
  6. Which limitations are well known and which are hidden.
  7. Which question about data volumes are relevant for success? Which not?

If you provide answers to those AND also describe the coarse steps/tasks for such an S2S project I will grant you a bounty afterwards.

Answer

What does end-user see?

Sender: List View > Forward To Connections > ‘External Sharing’ related list

s2s-send s2s-send-detail

Receiver: yellow nag on record detail

s2s-receive

How to enable S2S feature?

  • Log into a sandbox first (S2S makes permanent schema changes)
  • Create one new Account and one new Contact to represent “remote” org admin
  • Switch to Classic > Setup > Customize > Salesforce to Salesforce Settings
  • Enable Salesforce to Salesforce, then you will need to “invite” the remote admin’s contact
  • Remain in Classic, look for the new tab appearing in All Tabs > Connections (not setup!)
  • After connection setup, ‘Forward to Connections’ button appears on object list view

How much does it cost?

Salesforce to Salesforce is included in Enterprise Edition at no cost.

Is S2S a supported feature and best of breed?

Propellerheads and purists will groan out loud when they hear “Salesforce to Salesforce” but the underlying implementation of S2S itself is durable as far as the well defined bounds of pushing records across orgs.

Pros:

  • Uses pub/sub model, easy to grok and explain to customer
  • All background S2S operations are event-driven and asynchronous
  • Solution handover is assisted because you can point to Salesforce docs
  • S2S runs under its own integration user which offers some auditability
  • Automatically logs local/remote schema changes and record sync failures
  • For every record that doesn’t sync, admin receives an email with details

Cons:

  • Not quite real time, 1 minute typical
  • Often inappropriate for heavily customized orgs
  • Unrealistic customer expectations, risk behind apparent simplicity
  • There is no metadata. No source control. No change sets. 100% mouse forever.

What makes S2S easy?

  • Fast time to value, stand up working customer demo very quickly
  • Powerful graph capability, eg sync account AND its contacts/tasks in one go
  • If you spend 1 day playing with S2S you will find its constraints well defined

What makes S2S hard?

  • Bidirectional sync is fussy, each record must originate in one system
  • Anything off happy path gets messy, eg validation rules, picklist values etc
  • It is intended for syncing a limited subset of records, try not to fight that

Well known limitations

  • Only certain objects (and custom objects)
  • Any field change syncs the whole record

Not well known limitations

  • Forget State and Country picklists
  • Loops occur if the same field triggers updates on both sides of S2S.
  • There are undocumented rate limits like this:

** REQUEST_LIMIT_EXCEEDED**

The Salesforce to Salesforce operation from [Master] to [Slave] failed because the Rate limit either in [Master] or [Slave] was exceeded. Error Message: CODE – REQUEST_LIMIT_EXCEEDED. Message – ConcurrentPerOrgLongTxn Limit exceeded. We’ll retry the operation in an hour. If more attempts are needed, they’ll take place 2, 4, 8, and 16 hours after the previous retry.

What are the coarse steps?

  1. Proof of concept. Before going anywhere near an estimate or a chargeable service, just do it – smoke out a stupid simple bidirectional sync in 2 sandboxes. S2S has its peculiarities which must be experienced first hand. S2S is implemented with this in mind as sandboxes can only sync to other sandboxes, leaving production orgs untouched.

  2. Qualify the customer. Do they understand the analysis/overhead involved before AND after introducing S2S. Or do they expect it to be magical mind-reading glue between environments. The challenge is education: if customer pays money to build their custom bi-directional sync, you and they together will share the necessary analysis and learning along that journey. If customer does not have the requisite maturity, S2S turn-key OR custom-built sync will both be ‘tamagotchi’ solution requiring feeding and fixing all the time.

  3. Qualify the orgs. Is there a safe overlap in source and target orgs that it can be reasonable to expect objects and fields to line up, or are the environments already brittle, rapidly changing, nonsensical validations etc. Will upkeep of S2S config be able to match the changes in the orgs?

  4. Qualify the data. For the sales data will it sync a big hierarchy or mostly flat data? Or singularly set up some reference data? Will there be new records introduced into the system on an ongoing basis?

  5. Sign off the exact objects and limit to standard fields if at all possible. Implement one object in a sandbox and see if customer rejects it straight away because of (eg) the manual workflow to initiate the sync. Don’t run in and try to automate the sync initiation with Batch Apex or such, try and ensure real users take responsibility for syncing/forwarding any record.

  6. Add a checklist item “S2S sanity check” before any other integration with any of those objects, emphasize the need to train / socialize the existence of S2S and make sure it does not end up fighting against (eg) your duplicate management system.

Trivia

S2S can destroy data. Consider this scenario:

  • Setup bidirectional sync for field 1
  • Create a record in Master and sync it
  • Modify bidirectional sync to sync field 2
  • Update a record in Slave (sync will fire)
  • Slave overwrites Master field 2 value with blank (!)

Detect the S2S integration user:

  • Name: Connection User
  • UserType: Partner Network
  • Email: partnernetwork@orgid.pnet

For example to disable validation rules during sync:

/* Salesforce To Salesforce validation bypass */
NOT ISPICKVAL($User.UserType, 'PartnerNetwork') && ...

Connections take on the Organization Name of the remote org at setup time (forever and ever amen) so ensure all the synced orgs aren’t called “Salesforce.com, inc” to avoid permanent confusion.

Attribution
Source : Link , Question Author : Robert Sösemann , Answer Author : Community

Leave a Comment