Single- or Multi-Org Architecture? Six Factors to Consider

A few years ago, I was asked to recommend a Salesforce org strategy for a global corporation in a heavily regulated industry. This ask was part of a large transformational project, and the leadership team had already decided to stand up a single global ERP system. So implementing a single CRM system to run alongside it seemed like an obvious choice, right?

Single Org connected to a Global ERP System

It looked like making this decision was going to be pretty straightforward at first: stand up a single, global Salesforce org to handle all of the processes, integrate it with the ERP system, synchronize the data, and set up the appropriate permissions to make sure users could only see information that was relevant to their region. But after doing some research, I realized that being able consolidate all of your back-office processes into a single system doesn’t necessarily mean that you’ll be able to do the same for your front office processes.

Most of the legal regulations this organization had to comply with were related to the way it sold and marketed its products as opposed to the way it produced them. This meant that we could standardize the majority of manufacturing processes but sales, service, and marketing processes varied widely from region to region and there wasn’t much we could do about it. As a result, there were several considerations for our CRM strategy that we hadn’t needed to worry about on the ERP side:

• Sales, service, and marketing teams had to follow different sets of laws at local, regional, and national levels.
• Sales reps could sell products directly to customers in some places, but were required to go through third parties in others.
• The organization was permitted to offer certain types of services, like equipment maintenance, to customers in some regions, but not others.
• Content that could be included in marketing communications and who those communications could be sent to varied from region to region as well.
• Teams in each region worked only with the accounts, contacts, and products that were specific to their region. They didn’t need — and thus shouldn’t have — access to this information from other regions.
• The data our users needed to access also varied from region to region. Directors and Vice Presidents needed to view reports containing region-specific data, but executives needed to see summary data at a global level.

Some of these challenges were unique to this organization, but architects who work for global corporations often find themselves having to design solutions that meet similar sets of requirements. Identifying the best Salesforce org strategy to support those requirements is complex and requires careful consideration of a variety of factors. My team ultimately decided to go with a multi-org approach, even though it seemed counterintuitive at first.

Multiple Orgs connected to Global ERP and Global Analytics Platforms

Here’s a summary of the decisions we made along the way:

• Governance and Time-to-Market. Teams in different regions needed to be able to change their processes at different speeds to support new product offerings or to make adjustments for new regulations. We needed to balance the need for a good governance strategy with the need to avoid delaying the rollout of certain changes, which could have eroded the organization’s competitive advantage in the region where the changes were being implemented. A multi-org solution with separate orgs for each region helped to reduce bureaucracy and speed up innovation since each org had a smaller number of stakeholders responsible for approving changes.
• Process Alignment and Cross-Team Collaboration. Customers, product offerings, and processes varied so greatly from region to region that attempting to have teams in different locations use a shared org to collaborate with each other would have required many additional customizations to separate each region’s processes. The resulting increased complexity and long-term maintenance requirements would have negated any benefits associated with putting all of the users in a single org.
• Data Sharing and Roll-Up Reporting. Even though executives needed to see global summary data, the leadership teams below them needed visibility only to data that was relevant to their region. We decided that we could use an external reporting tool to meet the needs of the executives while using separate orgs for everyone else. This approach helped to reduce data volumes in each org, making it less likely that we would run into issues like data skew. It also eliminated the need for complex sharing rules to control visibility to region-specific data.
• User Access and License Costs. All of our business users worked with processes and data that were only relevant to their specific region. So, each user only had to be set up in a single org, which meant that a multi-org strategy had little effect on license costs. The only exception was the technical teams that were enhancing and maintaining the systems, as you’ll see below.
• Support Model. The organization relied on a central team to manage configuration and development. This added complexity to our multi-org approach because it meant that admins and developers would need to access multiple orgs and understand the way each individual org had been built. We decided that we were comfortable with the additional license costs since they only affected a handful of users. And we organized the support team in a way that allowed individuals to specialize in a given region, which helped to mitigate the need for admins and developers to understand the nuances of every org.
• Integration Complexity. Having multiple orgs connected to a single ERP system increased the number of integrations we had to build. This caused the most debate among team members because it definitely increased the complexity of the overall IT landscape. But we ultimately decided that as long as we employed the right middleware tools to manage our integrations, the benefits of our multi-org approach would outweigh the risks associated with having to build them.

We organized all of our observations into a chart like the one below. We thought of each decision as a spectrum where the requirements we needed to solve could clearly point to a shared org, clearly toward separate orgs, or land somewhere in the middle:

Org Strategy Decision List

Seeing everything laid out like this helped us to think about our architecture more holistically, and it became clear that using multiple orgs was the better approach. If you’re putting together an org strategy for your own organization, you’ll most likely run into some of the same issues. You might also encounter compliance issues related to data residency, which you can read more about in this post. As you go through your organization’s own list of considerations, you can use this approach to make sure that you’re not overlooking any key decision points.