Skip to content

Salesforce Org Strategy

gray and white concrete multi-story building during daytime
Introduction
Salesforce org strategy is one of the fundamental decisions for implementing Salesforce in your organization as it impacts almost everything in your architecture landscape.

In general, there are two possible approaches: single-org and multi-org. Where org means Salesforce organization – a deployment of Salesforce with a defined set of licensed users. An org is the virtual space provided to an individual customer of Salesforce. Your org includes all of your data and applications and is separate from all other orgs running in the multi-tenant Salesforce runtime. It also comes with certain platform limits enforced by Salesforce to ensure that each tenant is a “good citizen” of the Platform.
Multi-org options
The Multi-org approach can have few flavours:
  • Hub-and-spoke – where central hub org can be used for global data access
  • Point-to-Point – where each org is connected to all other orgs when needed, this scenario is getting messy fast as the complexity grows exponentially
  • Org autonomy – where each org is independent, this scenario is most interesting as still some level of unification can be achieved using packaged deployment model and global data access can be achieved with data hub pattern like Heroku or Data Lake
The whole discussion is getting even more interesting if there are other enterprise systems in play like MDM (Master Data Management), ERP, Order Management.

Salesforce’s value proposition is strongly correlated with the ability to stay on one org as this is the only approach where the Customer 360 view is for “free”. Every other scenario will result in much more complex architecture. I am not saying that single org is always the way to go, but in my view, this should always be the first option to evaluate and only go with the multi-org approach when there are evident requirements that can not be fulfilled with single-org.
Enterprise Architecture

The first thing we should understand when recommending an org strategy is the Enterprise Architecture operating model and the roles of Lines of Bussines (Departments) as well as the IT Team within the organization.

Enterprise Architecture as Strategy

Unification quadrant with High Business Process Standardization and High Business Process Integration should almost always have one org as staying in one org is the simplest way to achieve 360 Customer View and share data within one salesforce instance. It also simplifies significantly any multi-cloud solutions with B2B, B2C and Marketing Cloud in play.

Diversification on the opposite end with Low Business Process Standardization and Low Business Process Integration will almost always have multiple orgs as the majority of the one org benefits are not applicable and forcing one org approach will simply limit the Business Agility.

Replication quadrant with High Business Process Standardization and Low Business Process Integration seems also pretty straightforward as this is the “franchise” use case where each business unit will operate within independent org but the “core” functionality can be distributed with the unlocked packages so that it is only developed once and then rolled out across all organizations.

Last but not least the Coordination quadrant with Low Business Process Standardization and High Business Process Integration is the most difficult one as from the data integration perspective it is cheapest to stay on one org but it might be difficult to keep all the stakeholders and Lines of business “happy” within the limitations of one org.

How to make a decision
The reality is that IT and Architecture is only one point of view and it is very common in larger organizations that it is not the IT department that is calling the shots.

In order to be successful with Salesforce adoption, it is even more important to understand the Business context and structure sometimes even sacrificing the “ideal” architecture.

The ultimate question might be who is actually paying for Salesforce and what is the level of business alignment that is realistically possible within the company, as without proper governance and business alignment in place single-org approach, even if most elegant from the architecture standpoint, might become a failure.

Business alignment and strong governance framework is a key success factor for every Enterprise Salesforce implementation.
Other points to consider
Now when we do understand both the Enterprise Architecture model as well as the Business Context it is time to check some more detailed aspects that might drive the decision:
  • Legal and Data residency requirements (eg. Russia, China) might require a multi-org approach
  • Security and Visibility requirements – do you have strict security and visibility requirements as some out of the box behaviours might be challenging when there is a strict requirement to keep business unit data separated while still working on one global customer record (e.g. activity visibility)
  • Salesforce platform limits – is it technically feasible to host all the Lines of Bussines into single org without breaching Salesforce limits and causing performance problems
  • Data, Insights and Reporting strategy – what is your Enterprise Data strategy and how it will fit Salesforce org strategy Integration Strategy – what is the Enterprise
  • Integration pattern to enable a multi-org approach
  • Release Management and Governance – what would be your Release management strategy to ensure no unwanted cross Business Unit impacts of changes in Salesforce and integrated systems.
Conclusion
I hope this article helps to structure your approach for designing the strategy for your Salesforce orgs. This is an Enterprise Architecture level decision and should be treated as such, too many times I have seen organizations where this decision was forced by wrongly understood licencing costs, internal politics or timelines.

In order to drive long-term value from your Salesforce.com investment, you should treat this decision as a strategic one and make sure you evaluate the pros and cons of each option. When in doubt reach out to Salesforce Certified Technical Architect or one of the Salesforce Consulting Partners to help you with making the right decision.
Resources