Blogs » Architecture Track » Org strategy: Single Org Vs Multi Org

Org strategy: Single Org Vs Multi Org

  • Single Org Vs Multi-Org


    There are multiple times when you might come across a situation when you have to decide between a single or a multi org strategy. Large corporations have large business units which are quite different in term of how they operate and the business model. You might come across a situation when you might not be able to meet the requirements due to the diversity of the business's operating model.

    Sometimes, this might not even be in our control when a merger or an acquisition introduces another Salesforce org into our architecture.


    Let's look at what factors we should look at when deciding on our org strategy and choosing between a single or a multi org architecture.


    What's your operating model?

    These operating models shown above is extracted from "Enterprise Architecture as Strategy: Creating a Foundation for Business Execution", MIT Sloan.


    To understand this, Let's understand each quadrant one by one.


    The Unification quadrant

    This quadrant requires high business process standardization which means that the processes should more or less be the same. This quadrant should also be highly integrated. Hence, this quadrant goes well with a single org because, in a single org, all the data is in the same org and there is no need to integrate data from multiple Salesforce org.



    Image Source:


    The "Replication" quadrant

    This quadrant needs highly standardized business processes (which means they cannot be too different). The integration is less. Hence, the replication quadrant, as the name itself suggests is about replicating the business processes in multiple Salesforce orgs. So, these orgs would not need to be highly connected and will be almost similar. 



    Image Source:


    The "Diversification" quadrant

    The diversification quadrant needs multiple Salesforce org that need not have the same business processes. Hence, the orgs might be very different from each other based on the target business function it is solving or the target customers it is serving.

    Also, the business process integration required is "low" in this quadrant. Hence, this means that these orgs need not have a tight integration between the systems.



    The "Coordination" quadrant 

    The coordination quadrant, as the name itself suggests, needs coordination between the orgs since these orgs have high data integration requirements. The transactions performed in one org must be visible to the other org. However, the business processes standardization is low. Hence, need an org strategy where each org might have a very different business process, but they must all communicate & coordinate with each other.  



    If you're still not able to determine which org strategy works best, let's look at some of the factors which impact the decision to go for either one of the two. Here are the other considerations:


    System Integration design cost

    Multi-org at some point in time might require integration between them in order to communicate with each other. This integration might incur efforts & cost. Hence, we must verify if we are ready to invest the time & money required to implement multiple orgs.


    In Single Org architecture, all we need to care about are the other external systems that we need to integrate with. We need not worry about integrating other Salesforce orgs as well.


    License cost/budget

    The license cost & budget both are going to be higher in the multi org strategy in contrast to a single org, especially in case there are users who access multiple orgs.


    If we consolidate these users in a single org, we would save a lot of user licenses for those users who have access to multiple orgs. 


    Tailored experience

    Multi org gives a better user experience that is tailored to the specific users or target audience intended for the system. Although we can personalize the user experience using a variety of features like profiles, page layouts, record types, etc. it still isn't fine-grained when the audience is very diverse & different for example, in terms of the data model, if there is a group of people who need to use a field in a particular object and the other group of users doesn't need, we can only hide the field. However, the field will still stay in the DB and if we forget to hide it, it gets exposed to the unintended audience.


    Identity & Access management

    Identity and access management is a very important piece here because if there are multiple orgs and multiple user credentials for users, users might need to remember all their credentials. If a user has access to a single org and he has to remember the credentials, it is still okay but if there are multiple orgs, it ruins the user's experience and the users might keep forgetting their passwords also.

    A better option is to implement SSO into Salesforce so that the user has to remember only their official credentials and the same can be used to login to all the Salesforce orgs.


    Data governance

    In a single-org setup, it is very difficult to set up data governance and might require a large team to handle in contrast to a multi org. When the data is spread across orgs, each org can have it's own customised data governance in place. However, in a single org, the data governance might need to be standardised and cannot be customised. The complexity also increases in a single org as the data model is not customised either and has to be fit for all the business process running in the org.


    Duplicate management

    Duplicate management is an easier job when we have a single org. However, when we have multiple orgs, it becomes very complex, especially in case that multiple orgs have the same data model and might expect some kind of data. It is easy to clean the duplicates in the same org using validations, duplicate management tools. However, these don't work when the duplicate exists in a different system altogether. It might need a complex integration with all the systems to identify and get rid of these duplicates automatically and if this were to managed manually by an admin, it would be a very tedious job for the admin.


    Data Sharing/Security

    In and org that is being used by multiple users, need for fine grained security becomes very important. This is where multi org has an upper hand compared to single org. In single org, defining the data security for all the users might be difficult especially if there are multiple business units who need to use the same org and have a very different role hierarchy/structure.


    Governer limits

    If you have multiple orgs, you have a fresh set of governer limits for each org. Hence, you already get an upper hand in terms of the limits. However, there's no point in a fresh set of governer limits if you hardly utilize the limits. Even if you're hitting the governer limits, it is wise to ask yourself if just increasing the limits can help with the situation.


    Release management

    In a huge team working concurrently on the same org, we need to keep track of the releases by each team, changes, release cycles, etc. This complexity increases further with the number of sandboxes we have and if the releases cycles are closer to each other.

    In contrast, it is easier to manage multiple smaller teams working on a completely different org compared to a huge team working on a single org. Most of the time, the releases won't affect the other business entity or org, hence, we need not always keep track of their releases. This depends based on use cases because if all the orgs have a central server or a "Single Source Of Truth" where they all deploy, it might be a different story altogether.


    Enterprise-level reporting

    Enterprise-level reporting becomes very difficult when we have multiple orgs with data in each of them. Combining data from all the sources becomes a challenge in enterprise architecture. However, it is easier to fetch all the data from one source rather than multiple different orgs.


    Integration with components/third party systems

    Integration with third party systems depends on the architecture being used and how the system is being integrated. However, with a single org, it is easier to establish a single connection with a third party. Do look at the limitations on the number of connections you can establish with the third-party system. If the systems have a limiation, then multi org might not be a good idea.


    However, as a flip side as well If the amount of data being pushed from a single system is huge and causes a lot of delay, it might sometimes be a good idea to push it from multiple sources rather than one at once.


    Chatter Usage

    Does you organisation use chatter a lot?

    If your answer is yes, it is very difficult to integrate chatter from multiple orgs. People might have notifications from multiple chatter accounts. In single org, staff can use chatter and collaborate easily without the need to handle multiple chatter accounts.




No Stickers to Show