Single-org or Multiple-org – the BIG question

However, even at smaller organizations this question can be relevant in several situations. For example, a client that has multiple orgs due to various reasons (departments with own orgs, acquisition, different brands), may benefit from migrating to a single-org solution. Whereas a client which has only one highly customized org, intended for a specific department, can benefit from implementing multiple orgs, as it can be more complex to roll-out its customized org to the whole organization.

However, even at smaller organizations this question can be relevant in several situations. For example, a client that has multiple orgs due to various reasons (departments with own orgs, acquisition, different brands), may benefit from migrating to a single-org solution. Whereas a client which has only one highly customized org, intended for a specific department, can benefit from implementing multiple orgs, as it can be more complex to roll-out its customized org to the whole organization.

Unfortunately (or lucky for us architects), this question cannot be answered with a simple “single or multi-org” answer and is highly dependent on the requirements and the client itself. We, as architects, can help the client by investigating the situation using the following questions.

• What is the (enterprise) architecture and governance structure?
• What is the organizational structure?
• What are the data storage requirements?
• What are the (business) reporting requirements?
• How do we support a 360-customer view?
• Do Salesforce governor limits force us to go for a multi-org strategy?

What is the (enterprise) architecture and governance structure?

Especially for large enterprises, this question usually takes quite some effort and time to be properly answered. To introduce a single-org strategy, it is crucial that the surrounding enterprise landscape is standardized and centrally managed. For certain types of interfaces, such as data warehouses and email, it is a “nice to have” to hold one central Salesforce org. For other types of interfaces it is a strong should have. Think of seamless login via Single Sign-On or implementing a central chatter solution.

What is the organizational structure?

Another important topic to help you determine whether to use a single- or multi-org strategy is the organization structure. How are the departments structured within the organization and which business processes are shared between departments? A single-org strategy can be beneficial by providing data access and visibility within the whole organization. In a department driven organization this is not always seen as an advantage at first, people tend to work in silos and are not always eager in sharing data… But consider the following scenario: as Sales Manager you had a good sell last year, and are planning to visit the client. Wouldn’t it be great to be aware that the client is invited – by marketing – into a social event; or to know there is a complaint which is handled through the service department? Having a single-org strategy and shared processes will give your organization the power to share, which results in increased effectiveness by reducing time spent on – for example – internal email communication.

Another sample where a single-org strategy can be beneficial is in reducing the time-to-market for implementing business processes. This strategy allows the client to harmonize and re-use business processes. The client does not need to start from scratch over and over again, which empowers him with fast delivery. To fully benefit from the single-org strategy, it is essential to have central governance and stakeholder management in place to streamline business processes and requirements.

What are the data storage requirements?

As written above, a single-org strategy can be quite beneficial to the business when considering data storage requirements. Salesforce offers a wide set of techniques like role hierarchy, permissions, territory management and even custom apex sharing. These techniques allow you as an architect to come up with a proper design which ensures that users are seeing only the right data (and nothing more).

In certain situations however, regular or compliance rules apply, forcing the architect to advise a multi-org strategy (e.g. when data must be stored in certain countries or regions). Another solution for these scenarios is to apply a multi-instance strategy, which has its own pros and cons. Let me know if you would like to know more about this particular strategy, I’d be glad to tell you more about it.

What are the (business) reporting requirements?

It is important to investigate the reporting requirements. An organization’s goals can be to have organization wide reporting facilities and insights in business processes. Often, having multiple orgs without harmonized business processes and differentiating data models will lead to a mixed and unclear view on the data. In a single-org solution, departments are encouraged to harmonize their business processes and to operate within its boundaries. This offers a clear view on the data and provides the organization with organization wide reporting facilities.

Should I apply for a single-org strategy to support a 360-customer view?

“I need to have a 360 view; I need one org!” is a quote I often hear. When asking in more detail, the majority of data for the 360 view is stored outside the Salesforce.com platform. This data can be perfectly integrated using modern techniques like OData, third-party integration software (e.g. MuleSoft, Stich, Informatica) or even managed packages which can be bought in the AppExchange. Although a single-org strategy indeed has advantages in supporting a 360 view, in my opinion, this should never be the winning argument to decide for a single-org strategy.

Do Salesforce governor limits force us to go for a multi-org strategy?

This is one of the most complex questions to be answered. Although the platform’s features and limits are widened in each release, it still has limits. To answer this question, you need to perform an in-depth investigation into all business processes. Especially pay attention to those around the standard Salesforce objects: Accounts, Opportunity, Cases and Contracts. These objects are shared by a large set of users, often resulting in many configurations and customizations. This, in turn, can cause limits to be reached.

The topics above are a small portion of the investigation to answer the big question: single or multi-org strategy? Some other interesting topics to consider are:

• Who is paying the bill, for both licensing and global architecture?
• In a single-org strategy testing becomes increasingly important. Is your organization capable of supporting global (regression) testing to avoid production issues?
• Who do you trust to supervise overall architecture in a single-org solution?

Final words

So what strategy should you choose: single-org or multi-org? As you probably understand having read this article, there is no simple answer to this question. I hope this article provided you with insights to tackle the question and helps you make a fundamentally based decision. Enjoy the journey! And if you need someone to guide you to your decision, let me know!

About the author

Jan-Dirk Schreurs, Salesforce Technical Architect working for Brite with over 10 years of experience in implementing Salesforce.com for large and medium sized companies.
You can contact him via email: jandirk.schreurs@wearebrite.nlor https://www.linkedin.com/in/jandirkschreurs/