We are part of a global company. Our Salesforce instance is stand alone with no integration into our ERP. We are located in Australia.

We have had an unusual request to incorporate a New Zealand business unit into our Salesforce. We could easily just acquire several more licenses and carry on as normal and kind of treat them like another State of Australia however the New Zealand side of the business wants to incorporate their ERP system.

To make matters even more convoluted the New Zealand Company has a business side and a consumer side. Both of these arms of the New Zealand business will be using Salesforce and integrating with their ERP system.

The New Zealand business will employ a Salesforce Administrator to look after the NZ Consumer Salesforce Org and I’m assuming the integration to their ERP system. We have a different ERP system which will not be touching our Org. We also currently use Marketing Cloud and Partner Communities which will at some stage down the track be utalised by the NZ Business.

I want to get a handle on what should be the best way to approach this. Do we incorporate NZ Business into our Org and have only their Data integrate into their ERP or do we keep two separate Orgs and find a way to integrate their data into our Org. Or, is there a better option that I haven’t thought of?

Thanks, AUS/NZ

2 Answers 2


I have often found that answers to questions like this are more of politics than technology. The consultants and IT will be more focused on finding out intuitively decide what's the best and find out elements to support the intuition. Back to the question.

I would consider the below.

  1. Similarity/differences between business operations in the two countries. This will allow you to decide whether an integrated system makes sense.
  2. Org mandate to make business homogeneous or 'hyper-local'ed. Money spent on "consolidation" and "localisation" is way too much

Technically -

  1. Look at what the additional users mean - an addition of hundreds of rules where you distinguish between countries? If yes to later, stay as a different, else merge

  2. Dissimilar hierarchies that will require you to hack the hell out?

The information provided is at a high level, so don't consider this as final.

I consider both countries to be of similar market conditions and not quite different models. So, I will put them in one org. This will aid the future introduction of ERP for Australia (well, one can hope all things pleasant.)

This will certainly have reduced maintenance cost considering standardization of business activities (which you will be able to sell at all times).

Alternatives are not that difficult but certainly more painful for customizing applications. Instead of trying to maintain two different salesforce instances with their distinct code base, try to encourage reuse through packages created centrally - e.g. as a managed package or locked packages of the future.


This is more of an architectural decision and depends on several factors. In summary, Merging/Joining two Orgs is not an easy task. There's no right or wrong answer to this, it's just requires more of planning and execution.

Below is my take on this.

In general, not only restricted to any Org merge but any implementation has to be a planned activity. I usually try to identify the overall current situation vs. the future roadmap and start with 5W1H principles.

  1. Why - everything starts here, as why do you need to implement this (or merge the Orgs). This is the Business Requirement

  2. What - closely related to What, what is getting implemented, or what are the requirements, or what is getting impacted

  3. Who - is getting impacted. Usually the Users

  4. When - usually the timelines

    And then finally and most important,

  5. How - how are you going to implement it

While you will usually have answers to the 5W, the most critical and significant piece is the 1H. You will need to carefully evaluate as once you have the clarity, how are you going to take the first step towards your Org merge. You need to consider everything that you current instance is built upon, to name a few:

  1. Metadata - how are common entities viz., Account, Contact are same/different for both Business Units
  2. Data - what is the current volume of data vs. what will be brought over. You also need to consider de-dupe of records which may have existed in both instances
  3. Configurations/Customizations - what config/customizations (record types, validation rules, apex/triggers, etc.) you have in place which impacts common entities, and what is your plan to address those
  4. Edition/Licenses - what is the financial impact on upgrading your edition/licenses
  5. Very important and often missed is Regression - once an Org is merged, what is your plan for regression testing the existing implementation

Once you have listed down the important current implementation and the impact of any new merges, you will have a better idea as what is the overall impact of merging your Org.

Overall, what you need to perform here is an impact analysis before you can really take a call of merging two different Orgs.

As for your question:

Do we incorporate NZ Business into our Org and have only their Data integrate into their ERP or do we keep two separate Orgs and find a way to integrate their data into our Org. Or, is there a better option that I haven’t thought of?

If there's a common data that both your NZ and AUS Business Units will be dealing with, it's recommended that you keep a single source of truth for that. It depends what is your source of truth in this case. If you are dealing with data within Salesforce, then while merging consider de-duping the data to retain the quality.

However, if only one of the units need to integrate with ERP, you can always do that in a single instance. It just depends that the new integration will talk from your merged instance vs. the NZ instance.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .