Build Apps Like a Pro

Achieve App Builder Certification Become an App Builder Pro

Salesforce Multi Org Dilemma

What exactly is a Salesforce org? The Salesforce document glossary describes an org (or Organization), as “A deployment of Salesforce with a defined set of licensed users. An organization is the virtual space provided to an individual customer of Salesforce. Your organization includes all of your data and applications, and is separate from all other organizations.”

So, what is a multi-org situation? The multi-org situation that I refer to in the scope of this article is the situation where a business entity has their Salesforce production data and processes spread across different instances of Salesforce; thereby making it difficult to generate holistic views of data and business KPIs. This could be a conscious decision for some, but that may not be the case for all.

Idealistically speaking, it is very important for an organization to assess its org- strategy right from the beginning before the implementation snowballs into a web of un-necessary Salesforce orgs, which would give you issues later. But that is in an ideal world, where everything goes according to plan. In reality, there are multiple large conglomerates today who are wrestling with un-optimized org clusters to run their business. What would be the cause for such a situation? Lack of vision is one. But that is not the only reason.

One possible reason for an unwarranted multi-org situation is Mergers & Acquisitions. Salesforce is unarguably the number one CRM suite in the world, and therefore there is a good probability that a company you acquire also uses Salesforce. Another common business case is where different Salesforce instances are maintained for the different business lines, and there is not enough time spent optimizing these systems as the business grows. Similarly, there are also cases where companies created different orgs according to geography, and customer segments. So you see, when we are talking of a large global enterprise – a multi-org situation is not that un-common.

But every business would want to avoid data silos, and instead have global visibility required to measure business performance and identify opportunities for improvement or growth. So, what is the best approach towards planning your Salesforce org structure? Well, sadly there is no straight answer to the question. Every business needs to assess their needs and goals, vs. the parameters that apply in a multi-org environment, and arrive at an org-strategy that works best for them.

However, there are some common guiding principles for assessing the org-structure for your business.

The first consideration to make is how your business is structured. Is your business centrally controlled? That is, do you follow standardized processes and methodologies across your business lines? Is it critical that you need to centrally control the IT systems and have a common point of administration and decision making? If your answer is yes to questions like these – and you prefer to maintain a centrally controlled IT engine for all of your business lines – then you might want to consider adopting a single org-strategy. However, if you are a business conglomerate that allows independent functioning of your individual business lines, with minimal use of aggregated data; a multi-org strategy may work best for you. This is a common architecture seen in conglomerates that runs entirely un-related businesses, with different P&L statements.

Another aspect to consider is the way you plan to use the Salesforce analytics engine. In every business organization there would be a set of stakeholders wanting to slice and dice the business data. If the usual reporting needs revolve around drawing summaries out of data across different organizations, probably you need to re-look at your org-strategy. While designing your org strategy, it is important to ensure that there is only minimal effort in generating the required analytic dashboards.

However, centralizing administration might not always be the best thing to do. For a large corporation with huge data volumes, multiple business lines, and operating geographies; a centralized org administration strategy might not prove effective. It would overload your administrators, and inhibit business agility. Time taken to respond to a change in a local segment of the business would be much greater in this case. For companies that want to share the administrative load, and provide business flexibility, a multi-org strategy might prove more effective. Innovations and changes take longer to impact the business if you opt for a single org model, and have a large business ecosystem. But that is not a bad thing, if your business operating model places more importance on centralized control and globally aligned business processes.

Another parameter to add to your considerations on org-strategy is collaboration. The benefits of enterprise collaboration cannot be over stated, and Salesforce has been a game-changer in this space by launching Chatter. Chatter often is the catalyst for an up-sell or cross-sell opportunity. Having all your users in one org, means your users can collaborate on a common customer that spans across your product lines and business territories. Such kind of collaboration would require additional work and investment, if your users are scattered across multiple salesforce orgs.

So you would see, there is easy or right solution. Each enterprise has to assess their org strategy, keeping in view their business and operational future.

Now, how could one ensure the org-strategy is thoroughly considered? For starters, you ought to ensure that opinions and views from all stakeholders are considered. This is the precursor to many organizations setting up Global Excellence Center / Executive Groups / CoEs / and other such forums. The participants must meet on a regular basis, to take stock of the progress, the current bottlenecks, future state, and business impact. The group constitution must be constantly reviewed to ensure it stays relevant, as the business grows.

Also, from a project management perspective, you must carefully assess your in-house expertise in handling org migrations and merges. It might not be as simple as the day-to-day duties your in-house Salesforce team handles. You might want to partner with an external system integrator who has proven expertise in delivering org-strategy transitions. Also, it is recommended that you follow an iterative model of engagement for the reason that, org-transition projects are usually high risk and affects a large number of users. It is important for the stakeholders to be able to frequently assess how the changes are coming along, and provide corrective directions if required. Iterative model grants the desired agility.

Now, what exactly are your options when it comes to defining your salesforce org-strategy?

 

Single Org
This is of course is the methodology of merging and moving all your Salesforce data into one big consolidated Salesforce org. The primary benefits you stand to gain are the unified data view and standardized business processes. It probably is the most cost effective approach, in terms of an org-strategy. However, you are more likely to run into governor limits and other storage limits sooner with a single org approach.


Reporting Org
This is a methodology where a single org is maintained for reporting needs. All high level data is periodically copied into that org, and dashboards are generated and emailed from that org. Besides holistic view of data, the other advantage is that this approach is the least invasive one. That is, there are minimal changes and tweaks required in the existing Salesforce orgs.


Master Sync Org
This model is adopted when an organization necessarily want to have business running on multiple orgs, but still keep common data – like Account data – consistent across the orgs. For this, a new org is maintained for aiding synchronization and acts as the source of truth in terms of data. However this approach should be taken only if absolutely necessary, for this means additional licensing and operational costs.

 

Salesforce has been making continuous investments in this area, to aid the large enterprise customers with multiple orgs. One of the features that Salesforce has brought out to aid multi-org situation is S2S.Or, “Salesforce to Salesforce”. This is a framework for creating data sharing rules across multiple Salesforce orgs. It natively allows an org to publish data into another org. Multiple levels of data abstraction are available within this framework, that would help you achieve the right level of cross org data sharing. Another recent investment in this regard is Salesforce Lightning Connect Adapter. This is due in Summer 15, and would allow Salesforce to act as a data source for Lightning Connect. This would allow you to embed data from one Salesforce org, within another org, and thereby provide a holistic view – without having to spend storage space. Besides what is described previously there are third party applications like Informatica MDM, which allows you to achieve multi-org collaborations and data migrations.

On a closing note, Salesforce has provided its customers with a varied set of tools and resources for constructing an org-strategy to suit their business. It is upon the customers, and their ISV partners to arrive at an org-strategy that would work best for them. There is no magic pill for this, and careful assessment and considerations are required before going ahead with your revised org-strategy.

What Certification are you studying for now?

Focus on Force currently provides practice exams and study guides for sixteen certifications

Comments

  1. arus

    If the company decides to have a single ORG for multiple business lines and locations, what are the most effective tools to do that (roles, security rights)?

    1. Martin Gessner Focus Team Post author

      It really depends on the requirements. Should the multiple business lines be able to see each other’s data or not? If not, then robust sharing rules are a must to segregate the data.