To centralise or not to centralise? That’s the question.

To centralise or not to centralise? That’s the question.

To centralise or not to centralise? That’s the question.

It is fundamental to define the use of Salesforce for your organisation before designing and building a solution to deliver business results. So often, you will encounter terms like “Single org” and “Multi-org”, but the bottom line is it all comes down to making the decision on whether to centralise or not.

The title of this article might suggest that the decision on having a single or multiple orgs (i.e. Salesforce instances) is a rather philosophical question. Well, the philosophers amongst us might be disappointed because this decision should be based strictly on rational aspects and answers to logical questions. These questions have to be taken into consideration and answered upfront before making the right choice. 

The most elementary and fundamental questions relate to your enterprise architecture. The level of standardisation of your business process and the level of integration within your organisation are key parameters to decide on your organisational strategy.

A company with relatively standardised business processes and a high level of integration between business units requires a single org strategy. In contrast, separate businesses with entirely different processes, clients, products, and services can warrant a multi org strategy to support a desire for independent governance and facilitate independent requirements and procedures.

Let’s take a real example. 

Recently one of my clients wanted to move from an in-house developed CRM system to Salesforce Sales Cloud. The customer I’m referring to is active worldwide in the manufacturing industry, but only the European region was in scope. To give you an idea of the size of this company, they have about 1000 people in Europe spread across 30+ countries and six regions. Their operational sales model exists out of two different models, a direct sales channel and an indirect one through which they sell their products via channel partners (distributors).

Even though the in-house developed solution was a sustainable solution that served their business for more than ten years, a couple of challenges came around the corner as time went on. One of the main ones they encountered was the lack of data sharing possibilities across different entities, impacting the transparency negatively between them. A second challenge was an almost unmaintainable solution because of deviated business processes implemented over the years without having an appropriate business case for them. 

The customer did their homework and had a straightforward idea about their organisation's strategy. 

They went for a centralised approach across all European countries they’re working in, which was made after considering all the crucial aspects. Because of this choice, data is now transparent and available for each division, and reporting has been made very straightforward for management. Moreover, the workflow of each country is now standardised across the whole region, which implies clarity, an efficiency gain and last but not least, a maintainable solution with a faster time to market when changes are required. 

So, when we consider this scenario, what are the actual differences and the advantages of a centralised organisation versus a decentralised organisation? Let’s take a look. 


  • Ability to easily share functionality across countries, business units

  • Configuration and Development needs to happen once for everyone

  • Data can be easily shared across countries' business units, and top management can consolidate at the global level for central reporting

  • Maintenance effort is reduced (in development but also in user management - e.g. no need for SSO across several orgs)

  • Feature deployment to multiple entities at once

  • No need for extra licenses if one user needs to access data from multiple countries/business units

  • No licence cost for products to consolidate data for global reporting

  • Countries/business units need to design their processes in a global manner, which presents an opportunity to reassess and streamline old ways of working

  • Licence cost and implementation effort for any integration is reduced (e.g. marketing automation tools, ERP integration, other SF products)

  • If data management regulations apply, having all data in one server placed in a particular country is a problem: e.g. Russia, EU, Australia want their companies’ data to be stored within their territory. As a result, SF does not support one org strategy with data spread over multiple countries.

  • Feature Developments need to compromise much more as the design needs to consider each country/business unit. There are limitations to the exceptions per country, or the platform will become unmanageable.

  • Strong central governance is required whereby deviations from the standard process are only allowed if there is a legal requirement to do things differently or a significant commercial advantage to be gained. Without a strong governance model, the org can rapidly become messy and difficult to manage. 

  • Countries/business units need to design their processes globally, which will prove a long process, sometimes leading to project failure.

  • The risk of going over the organisational limits is significantly lower due to org-wide settings, which make governing and management more effortless.

  • The development and testing processes are less complicated, which results in the reduction of testing burdens. 

  • More extensive autonomy and agility, thanks to faster time to market.

  • Better visibility and security of data architecture.

  • Processes get more challenging to define across countries.

    • This is an important one: we can not emphasise enough that this has to be driven and carried by the business. We can support this change as a system integrator but not lead it. 

  • Complications when it comes to reporting on a global scale

  • Structuring and managing of data become more intricate

  • Cross-business-unit collaboration is harder

  • Additional complications for users (e.g. using more than one login)

To sum up, it is vital to consider all those dimensions, as mentioned earlier, when choosing the best-fitting architecture supporting the business model. Besides that, the level of readiness when it comes to support, data management, integration, governance, and maintenance has to be taken into account as well, and we can’t forget about the costs and regulations when making the final choice. 

Deciding if it’s better for your business to centralise or not is critical to any restructuring effort. Choosing the wrong model can impact your company’s efficiency and finances, but most importantly, the satisfaction of your customers and the engagement of your employees.

At Waeg, we have a great team of certified technical architects who can help you make this critical decision. If you want to get more information on this subject, don’t hesitate to reach out. I’d be delighted to set up a conversation and talk about this topic.

Nick Celis,  Business Development Director



TheChannel is all about where the waves take us. Going from ideas to results, experience to knowledge, expertise to success and practice to perfection. We invite you to join the Waeg world.