By Remi Poujeaux, SVP of Innovation at Odaseva
In the previous chapter in our “Salesforce Multi-Org Management” series, we explored the different possible strategies of Salesforce Orgs: independent, supervised, federated, and mirror.
In this chapter, we will explore the federated Salesforce Org strategy, which is the most powerful approach for large companies. A federated strategy enables companies to run separate Orgs for separate business units, while running the business as if there was a single Org.
Let’s explore the possible reasons to adopt this strategy and how it can be done.
Large companies may need to have multiple Salesforce Orgs for various reasons. However, these companies will want the ability to operate in certain areas as if there was a single Org.
Just imagine a company called EcoWonderful that has a Salesforce instance for each Business Unit. This would ensure the right level of autonomy, but at the cost of di-integrating the data and the process.
The complexity generated by EcoWonderful’s organizational and IT decisions should not endanger the customer experience. For example, a customer may purchase several of EcoWonderful’s products from different Business Units and is expecting a seamless customer service when purchasing and receiving service for each of the different products. The customer is expecting to have a single identity, one entry point such as a portal or a mobile app, a consolidated status of the cases and orders. They should not have to create different identities for each of the Business Units within EcoWonderful, because the customer’s experience shouldn’t suffer because the EcoWonderful’s Salesforce Orgs are separated.
Now, let’s imagine that each EcoWonderful Business Unit implements Salesforce in isolation. It is very likely that even if the guideline is to “stick to standard,” the configuration of the system will vary considerably, starting with the possible values for a case status, which is the backbone of a support process.
Salesforce is a very flexible tool, as it is getting customized.
The result will simply be that the customer won’t be able to get the optimal experience.
The federated approach is about defining and enforcing implementation of a core model which represents the common language across the Business units in terms of data and process. In the above example of EcoWonderful, this would be done by enforcing a single user identity across all Salesforce Orgs, standardizing the experience with shared web components and defining the mandatory shared data and metadata.
Just setting a canonical model and complex transformations rules should be avoided as it just gives the illusion of a common language. Nobody understands operationally a canonical model. Implementation of the core model should go down to the systems with a control mechanism to check that the configuration of the core model is consistent.
What is outside of the core model doesn’t need to be strongly governed.
The core model is about sharing
It most often requires data and metadata synchronization between Orgs that may be achieved in various ways, this will be the topic for the next chapter.