By Remi Poujeaux, SVP of Innovation at Odaseva
The previous post in our “Salesforce Multi-Org Management” series explored the federated Salesforce Org strategy.
In the final post in this series, we’ll discuss splitting and stitching Salesforce Orgs. In a Salesforce multi-Org landscape, there are three main activities:
Let’s explore each.
As we’ve seen in the previous chapters, there are many reasons why you would want to split an existing Salesforce Org in two (or more) Orgs.
First you need to define the data split rules: which data is going to each Org (or to both Orgs)?
This starts by defining simple business rules validated by the sponsors. For example, opportunities in China go to the China Org. This always looks simple, but the reality is more complex: what is an “opportunity in China”? Does it mean that the end customer is in China? The customer headquarters is in China? The product is installed in China?
There are then many ways to split the data:
In any case, you need to have the proper toolset, be able to move large and complex data and to check the final consistency.
In certain cases, you need to ensure consistency between your Orgs after they have been split in two. Or even get consistency between existing Orgs.
The level of consistency between your Orgs is driven by the definition of your core model, meaning that a subset of your data and/or metadata is aligned across the Orgs to control collaboration, consolidation and compliance.
Proper tooling is required for this. The control can be either proactive (locking the core metadata across your Orgs) or reactive by detecting discrepancies when extracting the data.
Let’s look at an example. ACME Co. wants to consolidate its opportunities worldwide. If each Salesforce Org has implemented a different sales process with different stages, this would be either impossible or at best very inaccurate, like comparing apples to oranges.
So the core model needs to define the opportunity stages and enforce them on all relevant Salesforce Orgs.
An Org merge project happens for two types of reasons:
It is unfortunately often seen as an IT project but in reality, it is first and foremost a business project. Merging means full alignment, no more concept of core model, no more flexibility – one Org for everybody.
A good way to prepare the merge is to have an Org stitch approach and progressively extend the core model scope. This is preparing the field for the final merge, both from a data and a user experience perspective.
Salesforce Org strategy is a complex topic but should always be driven (as with any IT strategy) from the business intent. Missed any of the other posts in this series? Read them here:
Learn the ways Odaseva can help by scheduling a demo today.
Data Protection
Data Security
Data Archiving
Data Compliance
Data Platform
