Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We have an OEM app, though could also be same question for AppExchange app. Are there downsides to using SF to SF from a packaged app...or with many customers? We provide a service in addition to software and are currently using SF to SF to get info into our Production org. Seems fine so far with 3 customers, but what about 300...3,000?

Yes we have to configure some of the connection info manually after install but outside of that?

share|improve this question
Is there anything as it pertains to packaging or other options? Data storage aside assuming we needed the records we are sharing, if we exchanged another way wouldn't API be same issue? If so I'm back to not seeing downside. – user2451 Feb 27 '13 at 1:02
If you need to pull the data into your Salesforce org, using the Webservices API to transfer the records will still consume the API. The question is more, do you want to store the data on Salesforce, or a different database platform and then just pull summary data into your salesforce instance. Ps - no one gets notified when you comment on your own question, you should comment on the answer to ask follow up questions – Ralph Callaway Feb 27 '13 at 15:40
did my answer address your question, if so could you accept the answer? – Ralph Callaway Apr 7 '13 at 19:27
up vote 10 down vote accepted

If you're using Salesforce to Salesforce to bring data from your customers org into Salesforce you're going to run into two scalability issues.

First, Salesforce to Salesforce transactions count against your daily API limit. If you have a lot of orgs connecting to yours there is a very good chance you could start exceeding your daily limit.

Second, storage limits in your org. As your number of customers increase the amount of data you're storing is going to increase quicker than your available storage.

Additionally, you have the additional risk that the customer may turn off Salesforce to Salesforce or mess up the configuration.

In terms of expectations for Salesforce to Salesforce, sharing basic records is very straightforward, but sharing complex relationships quickly starts to be a royal pain. A worst case example is sharing opportunities with products which requires first sharing accounts, and products, then the opportunity, and finally the opportunity line items.

In summary, you'll want to crunch the numbers for expected record volumes and API calls based on your current customers and compare it to what you get for free and then do a cost analysis for purchasing the additional storage/API calls. Depending on what that number is you might decide it's not the best option, or a great option. And as jkraybill suggested, you can structure your fees for the service to take into account the data volumes so that you can pass the additional cost on to the customer.

share|improve this answer
To add to this: one way to scalably address the storage issue is to make sure that you know the marginal cost of data storage per customer, and make sure that your fees for the service take this into account. Depending on your service, you may also be able to structure it so that you don't have to long-term store data for each customer. – jkraybill Feb 25 '13 at 2:33
good point @jkraybill, incorporated that into the answer – Ralph Callaway Feb 25 '13 at 16:29

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.