Much has been written and presented around Salesforce single organisation and multi-organisation strategies. But, still the question is asked quite frequently. There are really good articles and blogs and I'm hereby trying to compile the information and add my views to it, to provide a summary.
In a single org. approach, an organisation maintains one single Salesforce org. all their required operations (planned to be executed via Salesforce) are executed via same org.
Single Org. Approach
Ideal for: Small and Medium Businesses
- Less environment maintenance overhead
- Uniform processes - a very good opportunity for organisations which want to implement uniform processes/ functionalities across all units
- Easier user provisioning - once a user is setup, they have access to required functionalities
- Complicated processes as organisation grows larger and include various operations/ geographies
- Increased application conflicts - with same processes being used across different departments/ geographies, one change for a specific unit can impact other unit
- Performance issues - with same objects being used across different units, the data volume per object can substantially increase. This leads to special design consideration during design and development phase and also possibly performance degradation or limitations
Multi Org. Approach
Ideal for: Larger organisations with multi-country operations or multiple segregated business unitsNote:- It's not that large organisations should not use single organisation, but it's viability varies based on application usage & complexity, data volume and performance expectations.
- Flexibility to have unit specific operations within specific environment
- Higher Performance - Only unit specific data to be persisted in their Salesforce environment. Leading to better performing functionality
- Tailored Solution - Provides ability for each instance to have it's own tailor made solutions, to fulfil desired functionalities with less overhead. In an organisation having multiple segregated business units of Line of businesses, it can help segregate required functionalities/ data based on intended audience.
- Reporting - reporting can be complex if data from all (or multiple) organisations is required
- Process disparity - without proper control on design and architecture, the applications/ functionalities within each environment can become more and more disparate, leading to operations challenges
- Complex user provisioning - a user may be required to be setup in multiple organisations based on needs
- Licensing - If a user is required to access more than one organisation, they'll need to have dedicated user account in each org (unless a specific mechanism is built to expose data to them in some way). This leads to additional licensing costs
- Complex application maintenance - with some common functionalities across all organisations, it can be complex to roll-out changes in these functionalities across all organisations